* [PATCH V3] ARM: dts: da850-evm: use phandles to extend nodes
From: Sekhar Nori @ 2018-05-10 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xKXJnh5MSudY3FU_9Xw98PwDi3yaWTUdfjFDaE24NBrzw@mail.gmail.com>
On Thursday 10 May 2018 08:38 PM, Adam Ford wrote:
> On Thu, May 10, 2018 at 4:10 AM, Sekhar Nori <nsekhar@ti.com> wrote:
>> On Monday 07 May 2018 06:07 PM, Adam Ford wrote:
>>> Many node labels in the device tree (like serial0, serial1, etc) are being
>>> redefined, so let's modernize the device tree by using phandles to
>>> extend the existing nodes. This helps reduce the whitespace.
>>>
>>> Signed-off-by: Adam Ford <aford173@gmail.com>
>>
>> I applied this without the pmic changes. I am not convinced about those.
>> The tps node is already being referred to as phandle. I am not sure
>> referring to each individual regulator using phandle is needed. Other
>> files like am335x-evm.dts don't do it as well.
>
> I tested the regulator values and names after booting to see if the
> names and values matched the expected values. They did, so I am
> fairly confident it would have worked.
Not doubting that. But I am not sure if thats the "norm". Do you see any
other device-tree file doing this?
>
>>
>> Another thing is whether we really need the tp6507x.dtsi file. It does
>> not seem to contain much and also da850-evm.dts is the only file
>> including it. So it seems pretty pointless to me.
>
> Do you want me to do a patch that removes the tp6507x.dtsi file and
> just sets up the
> PMIC from scratch within the da850-evm file?
I am fine with the plan, but not something urgent, IMO.
>
>>
>> Here is what I committed.
>
> Thank you. I think looks cleaner this way, and more consistent with
> many of the other platforms and boards.
Yes.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] kvm: Change return type to vm_fault_t
From: Souptick Joarder @ 2018-05-10 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180419155606.45a85009.cohuck@redhat.com>
On Thu, Apr 19, 2018 at 7:26 PM, Cornelia Huck <cohuck@redhat.com> wrote:
> On Thu, 19 Apr 2018 00:49:58 +0530
> Souptick Joarder <jrdr.linux@gmail.com> wrote:
>
>> Use new return type vm_fault_t for fault handler. For
>> now, this is just documenting that the function returns
>> a VM_FAULT value rather than an errno. Once all instances
>> are converted, vm_fault_t will become a distinct type.
>>
>> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>>
>> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
>> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
>> ---
>> arch/mips/kvm/mips.c | 2 +-
>> arch/powerpc/kvm/powerpc.c | 2 +-
>> arch/s390/kvm/kvm-s390.c | 2 +-
>> arch/x86/kvm/x86.c | 2 +-
>> include/linux/kvm_host.h | 2 +-
>> virt/kvm/arm/arm.c | 2 +-
>> virt/kvm/kvm_main.c | 2 +-
>> 7 files changed, 7 insertions(+), 7 deletions(-)
>
> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
If no further comment, We would like to get this
patch in queue for 4.18.
^ permalink raw reply
* [patch v18 0/4] JTAG driver introduction
From: Oleksandr Shamray @ 2018-05-10 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff739c26-d3b2-3df7-e751-fbf037ae96d1@gmail.com>
Hi Florian.
>> We propose to implement general JTAG interface and infrastructure
>> to communicate with user layer application. In such way, we can
>> have the standard JTAG interface core part and separation from
>> specific HW implementation.
>
>Well, the framework in its current shape is still extremely
>simplistic, therefore leaving a lot of room (read: bugs,
>inconsistencies) within the hands of the driver, so while the
>user-space interface is standard through the proposed character
>device, the user experience, likely might not.
Well, the framework is intentionally simply and provide the very basic
interface. It supposed that interface can be extended in the future, if
necessary. Current kernel does not provide a framework for JTAG interface,
and we believe this is good starting point to allow such framework. This
provide minimal, but sufficient interface and any future extension will be
of course welcomed.
At the moment we have one controller driver, which works well with this
infrastructure. And we have very reasonable use case - this driver allows
flashing for all the programmable devices, connected to JTAG interface,
where the image for these device is provided with the standard SVF format.
>> This allow new capability to debug the CPU or program system's
>> device via BMC without additional devices nor cost.
>If that is the case, should not we leverage the kernel's device
>driver model and expect the JTAG framework to create specific devices
>for the different pieces of HW discovered on the scan chain? That
>would also
>presumably allow the core JTAG framework to retain the necessary
>state
>changes in order to address one particular device within the scan chain.
For the device programming use case, the flashing image will contain
jtag chain topology. If for example, jtag domain contains x devices, but
image contains less, the only relevant devices will be flashed and there is
no need to distinct between them.
In case there are several domains, jtag interface is configured to be
connected to the relevant one.
For the CPU debug use case, jtag interface is configured to be connected
to CPU only.
System should be able to provide jtag selection according to the needs
and this kind of operations should be out of the JTAG driver scope.
>> This patch purpose is to add JTAG master core infrastructure by
>> defining new JTAG class and provide generic JTAG interface to allow
>> hardware specific drivers to connect this interface.
>> This will enable all JTAG drivers to use the common interface part
>> and will have separate for hardware implementation.
>Let's consider I want to get rid of OpenOCD, or rather, move its
>driver interface within the kernel and replace it on the OpenOCD side
>with a generic character device interface. I could presumably
>amortize the costly operations which are currently I/O and/or system
>call limiting when running in user-space, what would it look like
>with your proposed framework, have you given some thoughts about that?
The JTAG driver using SDR/SIR transactions to send/receive data.
It can send/receive multiple data bits by a single transaction.
For the bit-banging style drivers it gives you an advantage of sending
Bits stream by one system call vs per-bit system call.
So, instead of updating GPIO pins a few time through user space interface
(sysfs) for sending single bit, an application can send multiple bits in a
stream by one call. And all GPIO operations will be performed than in a
kernel space.
It'll be necessary to have bit-banging driver, using the JTAG infrastructure,
which should be configured according to the particular system during
initialization. And we are planning to develop such kind of driver.
It definitely reduces system calls and saves time for JTAG operations.
For the system equipped with the JTAG master there the same advantages
plus hardware acceleration for pin access (all pins can be accessed by
one shot).
Driver supports universal transactions (include/uapi/linux/jtag.h),
which are sent through IOCTL interface JTAG_IOCRUNTEST, JTAG_IOCXFER
struct struct jtag_xfer {
__u8 type;
__u8 direction;
__u8 endstate;
__u8 padding;
__u32 length;
__u64 tdio;
};
jtag_run_test_idle {
__u8 reset;
__u8 endstate;
__u8 tck;
};
You can see usage example on https://github.com/mellanoxbmc/mellanox-bmc-tools/tree/master/mlnx_cpldprog
Best Regards,
Oleksandr Shamray
> -----Original Message-----
> From: Florian Fainelli [mailto:f.fainelli at gmail.com]
> Sent: 31 ?????? 2018 ?. 5:03
> To: Oleksandr Shamray <oleksandrs@mellanox.com>;
> gregkh at linuxfoundation.org; arnd at arndb.de
> Cc: linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> devicetree at vger.kernel.org; openbmc at lists.ozlabs.org; joel at jms.id.au;
> jiri at resnulli.us; tklauser at distanz.ch; linux-serial at vger.kernel.org; Vadim
> Pasternak <vadimp@mellanox.com>; system-sw-low-level <system-sw-low-
> level at mellanox.com>; robh+dt at kernel.org; openocd-devel-
> owner at lists.sourceforge.net; linux-api at vger.kernel.org;
> davem at davemloft.net; mchehab at kernel.org
> Subject: Re: [patch v18 0/4] JTAG driver introduction
>
> On 01/29/2018 06:31 AM, Oleksandr Shamray wrote:
> > When a need raise up to use JTAG interface for system's devices
> > programming or CPU debugging, usually the user layer application
> > implements jtag protocol by bit-bang or using a proprietary connection
> > to vendor hardware.
> > This method can be slow and not generic.
> >
> > We propose to implement general JTAG interface and infrastructure to
> > communicate with user layer application. In such way, we can have the
> > standard JTAG interface core part and separation from specific HW
> > implementation.
> > This allow new capability to debug the CPU or program system's device
> > via BMC without additional devices nor cost.
>
> Oleksandr, you have completed dodged my questions here:
>
> https://lkml.org/lkml/2017/12/25/163
>
> can you try to respond to some of these questions please?
> --
> Florian
^ permalink raw reply
* [PATCH V3] ARM: dts: da850-evm: use phandles to extend nodes
From: Adam Ford @ 2018-05-10 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ae8292b2-b167-7a96-70be-1cfea6059874@ti.com>
On Thu, May 10, 2018 at 4:10 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> On Monday 07 May 2018 06:07 PM, Adam Ford wrote:
>> Many node labels in the device tree (like serial0, serial1, etc) are being
>> redefined, so let's modernize the device tree by using phandles to
>> extend the existing nodes. This helps reduce the whitespace.
>>
>> Signed-off-by: Adam Ford <aford173@gmail.com>
>
> I applied this without the pmic changes. I am not convinced about those.
> The tps node is already being referred to as phandle. I am not sure
> referring to each individual regulator using phandle is needed. Other
> files like am335x-evm.dts don't do it as well.
I tested the regulator values and names after booting to see if the
names and values matched the expected values. They did, so I am
fairly confident it would have worked.
>
> Another thing is whether we really need the tp6507x.dtsi file. It does
> not seem to contain much and also da850-evm.dts is the only file
> including it. So it seems pretty pointless to me.
Do you want me to do a patch that removes the tp6507x.dtsi file and
just sets up the
PMIC from scratch within the da850-evm file?
>
> Here is what I committed.
Thank you. I think looks cleaner this way, and more consistent with
many of the other platforms and boards.
adam
>
> Thanks,
> Sekhar
>
> ---8<---
> commit ae62a32d6019a8225e2c32e631b8b0d039151131 (refs/heads/v4.18/dt)
> Author: Adam Ford <aford173@gmail.com>
> AuthorDate: Mon May 7 07:37:21 2018 -0500
> Commit: Sekhar Nori <nsekhar@ti.com>
> CommitDate: Thu May 10 14:01:15 2018 +0530
>
> ARM: dts: da850-evm: use phandles to extend nodes
>
> Many node labels in the device tree (like serial0, serial1, etc) are being
> redefined, so let's modernize the device tree by using phandles to
> extend the existing nodes. This helps reduce the whitespace.
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
> [nsekhar at ti.com: drop tps6507x related changes]
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>
> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
> index 339cae353302..9389f95f4094 100644
> --- a/arch/arm/boot/dts/da850-evm.dts
> +++ b/arch/arm/boot/dts/da850-evm.dts
> @@ -27,143 +27,6 @@
> spi0 = &spi1;
> };
>
> - soc at 1c00000 {
> - pmx_core: pinmux at 14120 {
> - status = "okay";
> -
> - mcasp0_pins: pinmux_mcasp0_pins {
> - pinctrl-single,bits = <
> - /*
> - * AHCLKX, ACLKX, AFSX, AHCLKR, ACLKR,
> - * AFSR, AMUTE
> - */
> - 0x00 0x11111111 0xffffffff
> - /* AXR11, AXR12 */
> - 0x04 0x00011000 0x000ff000
> - >;
> - };
> - nand_pins: nand_pins {
> - pinctrl-single,bits = <
> - /* EMA_WAIT[0], EMA_OE, EMA_WE, EMA_CS[4], EMA_CS[3] */
> - 0x1c 0x10110110 0xf0ff0ff0
> - /*
> - * EMA_D[0], EMA_D[1], EMA_D[2],
> - * EMA_D[3], EMA_D[4], EMA_D[5],
> - * EMA_D[6], EMA_D[7]
> - */
> - 0x24 0x11111111 0xffffffff
> - /* EMA_A[1], EMA_A[2] */
> - 0x30 0x01100000 0x0ff00000
> - >;
> - };
> - };
> - serial0: serial at 42000 {
> - status = "okay";
> - };
> - serial1: serial at 10c000 {
> - status = "okay";
> - };
> - serial2: serial at 10d000 {
> - status = "okay";
> - };
> - rtc0: rtc at 23000 {
> - status = "okay";
> - };
> - i2c0: i2c at 22000 {
> - status = "okay";
> - clock-frequency = <100000>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&i2c0_pins>;
> -
> - tps: tps at 48 {
> - reg = <0x48>;
> - };
> - tlv320aic3106: tlv320aic3106 at 18 {
> - #sound-dai-cells = <0>;
> - compatible = "ti,tlv320aic3106";
> - reg = <0x18>;
> - status = "okay";
> -
> - /* Regulators */
> - IOVDD-supply = <&vdcdc2_reg>;
> - /* Derived from VBAT: Baseboard 3.3V / 1.8V */
> - AVDD-supply = <&vbat>;
> - DRVDD-supply = <&vbat>;
> - DVDD-supply = <&vbat>;
> - };
> - tca6416: gpio at 20 {
> - compatible = "ti,tca6416";
> - reg = <0x20>;
> - gpio-controller;
> - #gpio-cells = <2>;
> - };
> - };
> - wdt: wdt at 21000 {
> - status = "okay";
> - };
> - mmc0: mmc at 40000 {
> - max-frequency = <50000000>;
> - bus-width = <4>;
> - status = "okay";
> - pinctrl-names = "default";
> - pinctrl-0 = <&mmc0_pins>;
> - };
> - spi1: spi at 30e000 {
> - status = "okay";
> - pinctrl-names = "default";
> - pinctrl-0 = <&spi1_pins &spi1_cs0_pin>;
> - flash: m25p80 at 0 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> - compatible = "m25p64";
> - spi-max-frequency = <30000000>;
> - m25p,fast-read;
> - reg = <0>;
> - partition at 0 {
> - label = "U-Boot-SPL";
> - reg = <0x00000000 0x00010000>;
> - read-only;
> - };
> - partition at 1 {
> - label = "U-Boot";
> - reg = <0x00010000 0x00080000>;
> - read-only;
> - };
> - partition at 2 {
> - label = "U-Boot-Env";
> - reg = <0x00090000 0x00010000>;
> - read-only;
> - };
> - partition at 3 {
> - label = "Kernel";
> - reg = <0x000a0000 0x00280000>;
> - };
> - partition at 4 {
> - label = "Filesystem";
> - reg = <0x00320000 0x00400000>;
> - };
> - partition at 5 {
> - label = "MAC-Address";
> - reg = <0x007f0000 0x00010000>;
> - read-only;
> - };
> - };
> - };
> - mdio: mdio at 224000 {
> - status = "okay";
> - pinctrl-names = "default";
> - pinctrl-0 = <&mdio_pins>;
> - bus_freq = <2200000>;
> - };
> - eth0: ethernet at 220000 {
> - status = "okay";
> - pinctrl-names = "default";
> - pinctrl-0 = <&mii_pins>;
> - };
> - gpio: gpio at 226000 {
> - status = "okay";
> - };
> - };
> vbat: fixedregulator0 {
> compatible = "regulator-fixed";
> regulator-name = "vbat";
> @@ -200,6 +63,153 @@
> };
> };
>
> +&pmx_core {
> + status = "okay";
> +
> + mcasp0_pins: pinmux_mcasp0_pins {
> + pinctrl-single,bits = <
> + /*
> + * AHCLKX, ACLKX, AFSX, AHCLKR, ACLKR,
> + * AFSR, AMUTE
> + */
> + 0x00 0x11111111 0xffffffff
> + /* AXR11, AXR12 */
> + 0x04 0x00011000 0x000ff000
> + >;
> + };
> + nand_pins: nand_pins {
> + pinctrl-single,bits = <
> + /* EMA_WAIT[0], EMA_OE, EMA_WE, EMA_CS[4], EMA_CS[3] */
> + 0x1c 0x10110110 0xf0ff0ff0
> + /*
> + * EMA_D[0], EMA_D[1], EMA_D[2],
> + * EMA_D[3], EMA_D[4], EMA_D[5],
> + * EMA_D[6], EMA_D[7]
> + */
> + 0x24 0x11111111 0xffffffff
> + /* EMA_A[1], EMA_A[2] */
> + 0x30 0x01100000 0x0ff00000
> + >;
> + };
> +};
> +
> +&serial0 {
> + status = "okay";
> +};
> +
> +&serial1 {
> + status = "okay";
> +};
> +
> +&serial2 {
> + status = "okay";
> +};
> +
> +&rtc0 {
> + status = "okay";
> +};
> +
> +&i2c0 {
> + status = "okay";
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_pins>;
> +
> + tps: tps at 48 {
> + reg = <0x48>;
> + };
> + tlv320aic3106: tlv320aic3106 at 18 {
> + #sound-dai-cells = <0>;
> + compatible = "ti,tlv320aic3106";
> + reg = <0x18>;
> + status = "okay";
> +
> + /* Regulators */
> + IOVDD-supply = <&vdcdc2_reg>;
> + /* Derived from VBAT: Baseboard 3.3V / 1.8V */
> + AVDD-supply = <&vbat>;
> + DRVDD-supply = <&vbat>;
> + DVDD-supply = <&vbat>;
> + };
> + tca6416: gpio at 20 {
> + compatible = "ti,tca6416";
> + reg = <0x20>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> +};
> +
> +&wdt {
> + status = "okay";
> +};
> +
> +&mmc0 {
> + max-frequency = <50000000>;
> + bus-width = <4>;
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins>;
> +};
> +
> +&spi1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi1_pins &spi1_cs0_pin>;
> + flash: m25p80 at 0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "m25p64";
> + spi-max-frequency = <30000000>;
> + m25p,fast-read;
> + reg = <0>;
> + partition at 0 {
> + label = "U-Boot-SPL";
> + reg = <0x00000000 0x00010000>;
> + read-only;
> + };
> + partition at 1 {
> + label = "U-Boot";
> + reg = <0x00010000 0x00080000>;
> + read-only;
> + };
> + partition at 2 {
> + label = "U-Boot-Env";
> + reg = <0x00090000 0x00010000>;
> + read-only;
> + };
> + partition at 3 {
> + label = "Kernel";
> + reg = <0x000a0000 0x00280000>;
> + };
> + partition at 4 {
> + label = "Filesystem";
> + reg = <0x00320000 0x00400000>;
> + };
> + partition at 5 {
> + label = "MAC-Address";
> + reg = <0x007f0000 0x00010000>;
> + read-only;
> + };
> + };
> +};
> +
> +&mdio {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&mdio_pins>;
> + bus_freq = <2200000>;
> +};
> +
> +ð0 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&mii_pins>;
> +};
> +
> +&gpio {
> + status = "okay";
> +};
> +
> /include/ "tps6507x.dtsi"
>
> &tps {
^ permalink raw reply
* [PATCH] ASoC: zx-i2s: fix spelling mistake: "timeing" -> "timing"
From: Colin King @ 2018-05-10 14:58 UTC (permalink / raw)
To: linux-arm-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in dev_err message text
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
sound/soc/zte/zx-i2s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/zte/zx-i2s.c b/sound/soc/zte/zx-i2s.c
index 9a0565937d1f..b6b056c607fa 100644
--- a/sound/soc/zte/zx-i2s.c
+++ b/sound/soc/zte/zx-i2s.c
@@ -197,7 +197,7 @@ static int zx_i2s_set_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt)
val |= (ZX_I2S_TIMING_I2S | ZX_I2S_TIMING_LSB_JUSTIF);
break;
default:
- dev_err(cpu_dai->dev, "Unknown i2s timeing\n");
+ dev_err(cpu_dai->dev, "Unknown i2s timing\n");
return -EINVAL;
}
--
2.17.0
^ permalink raw reply related
* [PATCH v1 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: Robin Murphy @ 2018-05-10 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525943800-14095-3-git-send-email-djw@t-chip.com.cn>
On 10/05/18 10:16, djw at t-chip.com.cn wrote:
> From: Levin Du <djw@t-chip.com.cn>
>
> Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
> which do not belong to the general pinctrl.
>
> Adding gpio-syscon support makes controlling regulator or
> LED using these special pins very easy by reusing existing
> drivers, such as gpio-regulator and led-gpio.
>
> Signed-off-by: Levin Du <djw@t-chip.com.cn>
>
> ---
>
> Changes in v1:
> - Refactured for general gpio-syscon usage for Rockchip SoCs.
> - Add doc rockchip,gpio-syscon.txt
>
> .../bindings/gpio/rockchip,gpio-syscon.txt | 41 ++++++++++++++++++++++
> drivers/gpio/gpio-syscon.c | 30 ++++++++++++++++
> 2 files changed, 71 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> new file mode 100644
> index 0000000..e4c1650
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
> @@ -0,0 +1,41 @@
> +* Rockchip GPIO support for GRF_SOC_CON registers
> +
> +Required properties:
> +- compatible: Should contain "rockchip,gpio-syscon".
> +- gpio-controller: Marks the device node as a gpio controller.
> +- #gpio-cells: Should be two. The first cell is the pin number and
I would suggest s/pin number/bit number in the associated GRF register/
here. At least in this RK3328 case there's only one pin, which isn't
numbered, and if you naively considered it pin 0 of this 'bank' you'd
already have the wrong number. Since we're dealing with the "random
SoC-specific controls" region of the GRF as opposed to the
relatively-consistent and organised pinmux parts, I don't think we
should rely on any assumptions about how things are laid out.
I was initially going to suggest a more specific compatible string as
well, but on reflection I think the generic "rockchip,gpio-syscon" for
basic "flip this single GRF bit" functionality actually is the right way
to go. In the specific RK3328 GPIO_MUTE case, there look to be 4 bits in
total related to this pin - the enable, value, and some pull controls
(which I assume apply when the output is disabled) - if at some point in
future we *did* want to start explicitly controlling the rest of them
too, then would be a good time to define a separate
"rockchip,rk3328-gpio-mute" binding (and probably a dedicated driver)
for that specialised functionality, independently of this basic one.
> + the second cell is used to specify the gpio polarity:
> + 0 = Active high,
> + 1 = Active low.
> +- gpio,syscon-dev: Should contain <grf_phandle syscon_offset 0>.
> + If declared as child of the grf node, the grf_phandle can be 0.
> +
> +Example:
> +
> +1. As child of grf node:
> +
> + grf: syscon at ff100000 {
> + compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
> +
> + gpio_syscon10: gpio-syscon10 {
> + compatible = "rockchip,gpio-syscon";
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio,syscon-dev = <0 0x0428 0>;
> + };
> + };
> +
> +
> +2. Not child of grf node:
> +
> + grf: syscon at ff100000 {
> + compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
> + //...
> + };
> +
> + gpio_syscon10: gpio-syscon10 {
> + compatible = "rockchip,gpio-syscon";
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio,syscon-dev = <&grf 0x0428 0>;
> + };
> diff --git a/drivers/gpio/gpio-syscon.c b/drivers/gpio/gpio-syscon.c
> index 7325b86..e24b408 100644
> --- a/drivers/gpio/gpio-syscon.c
> +++ b/drivers/gpio/gpio-syscon.c
> @@ -135,6 +135,32 @@ static const struct syscon_gpio_data clps711x_mctrl_gpio = {
> .dat_bit_offset = 0x40 * 8 + 8,
> };
>
> +static void rockchip_gpio_set(struct gpio_chip *chip, unsigned int offset,
> + int val)
> +{
> + struct syscon_gpio_priv *priv = gpiochip_get_data(chip);
> + unsigned int offs;
> + u8 bit;
> + u32 data;
> + int ret;
> +
> + offs = priv->dreg_offset + priv->data->dat_bit_offset + offset;
data->dat_bit_offset is always 0 here, but given that wrapping large
offsets to successive GRF registers doesn't make sense (and wouldn't
work anyway with this arithmetic) I don't think you even need this
calculation of offs at all...
> + bit = offs % SYSCON_REG_BITS;
... since it would suffice to use offset here...
> + data = (val ? BIT(bit) : 0) | BIT(bit + 16);
> + ret = regmap_write(priv->syscon,
> + (offs / SYSCON_REG_BITS) * SYSCON_REG_SIZE,
... and priv->dreg_offset here.
Robin.
> + data);
> + if (ret < 0)
> + dev_err(chip->parent, "gpio write failed ret(%d)\n", ret);
> +}
> +
> +static const struct syscon_gpio_data rockchip_gpio_syscon = {
> + /* Rockchip GRF_SOC_CON Bits 0-15 */
> + .flags = GPIO_SYSCON_FEAT_OUT,
> + .bit_count = 16,
> + .set = rockchip_gpio_set,
> +};
> +
> #define KEYSTONE_LOCK_BIT BIT(0)
>
> static void keystone_gpio_set(struct gpio_chip *chip, unsigned offset, int val)
> @@ -175,6 +201,10 @@ static const struct of_device_id syscon_gpio_ids[] = {
> .compatible = "ti,keystone-dsp-gpio",
> .data = &keystone_dsp_gpio,
> },
> + {
> + .compatible = "rockchip,gpio-syscon",
> + .data = &rockchip_gpio_syscon,
> + },
> { }
> };
> MODULE_DEVICE_TABLE(of, syscon_gpio_ids);
>
^ permalink raw reply
* Spectre and Cortex-A8/A9
From: Tony Lindgren @ 2018-05-10 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7x+ghEW__YwgbXYO4g9HNKkwkQtXiswL1jihj0wwfKuR4Q@mail.gmail.com>
* Adam Ford <aford173@gmail.com> [180509 18:23]:
> There is a lot of information pushed around the web about the Spectre
> bug. I went to ARM's support site and there are some patches
> available from February that haven't made their way into the mainline.
>
> Sorry if this has been covered before, but I am curious to know if
> there is a good place or method to determine whether or not the
> Cortex-A8 and A9 are still vulnerable and which versions or 4.4, 4.9,
> or 4.14 have any items fixed.
Well while we're waiting to figure out what all needs to be fixed,
here's what I'd do meanwhile:
1. Make sure the bootloader sets IBE bit
2. Make sure you have CONFIG_ARM_ERRATA_430973=y
3. Apply Marc Zyngier's patches from thread "[PATCH v4 0/6] 32bit ARM
branch predictor hardening", but note that these are still being
discussed
4. Update kernel when patches that have been validated against
test cases get merged
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: dts: socfpga: Fix NAND controller clock supply
From: Marek Vasut @ 2018-05-10 14:37 UTC (permalink / raw)
To: linux-arm-kernel
The Denali NAND x-clock should be supplied by nand_x_clk, not by
nand_clk. Fix this, otherwise the Denali driver gets incorrect
clock frequency information and incorrectly configures the NAND
timing.
Signed-off-by: Marek Vasut <marex@denx.de>
Fixes: d837a80d19 ("ARM: dts: socfpga: add nand controller nodes")
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Cc: Dinh Nguyen <dinguyen@kernel.org>
---
arch/arm/boot/dts/socfpga.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index d697f5062624..e719c20a0e65 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -750,7 +750,7 @@
reg-names = "nand_data", "denali_reg";
interrupts = <0x0 0x90 0x4>;
dma-mask = <0xffffffff>;
- clocks = <&nand_clk>;
+ clocks = <&nand_x_clk>;
status = "disabled";
};
--
2.16.2
^ permalink raw reply related
* [PATCH v6 09/11] firmware: xilinx: Add debugfs for clock control APIs
From: Sudeep Holla @ 2018-05-10 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1523389127-14243-10-git-send-email-jollys@xilinx.com>
On 10/04/18 20:38, Jolly Shah wrote:
> From: Rajan Vaja <rajanv@xilinx.com>
>
> Add debugfs file to control clocks using firmware APIs
> through debugfs interface.
>
> Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> Signed-off-by: Jolly Shah <jollys@xilinx.com>
> ---
> drivers/firmware/xilinx/zynqmp-debug.c | 48 ++++++++++++++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/drivers/firmware/xilinx/zynqmp-debug.c b/drivers/firmware/xilinx/zynqmp-debug.c
> index 1cb69f7..837fcd1 100644
> --- a/drivers/firmware/xilinx/zynqmp-debug.c
> +++ b/drivers/firmware/xilinx/zynqmp-debug.c
> @@ -34,6 +34,15 @@ static struct pm_api_info pm_api_list[] = {
> PM_API(PM_GET_API_VERSION),
> PM_API(PM_IOCTL),
> PM_API(PM_QUERY_DATA),
> + PM_API(PM_CLOCK_ENABLE),
> + PM_API(PM_CLOCK_DISABLE),
> + PM_API(PM_CLOCK_GETSTATE),
> + PM_API(PM_CLOCK_SETDIVIDER),
> + PM_API(PM_CLOCK_GETDIVIDER),
> + PM_API(PM_CLOCK_SETRATE),
> + PM_API(PM_CLOCK_GETRATE),
> + PM_API(PM_CLOCK_SETPARENT),
> + PM_API(PM_CLOCK_GETPARENT),
> };
>
> /**
> @@ -87,6 +96,7 @@ static int process_api_request(u32 pm_id, u64 *pm_api_arg, u32 *pm_api_ret)
> const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
> u32 pm_api_version;
> int ret;
> + u64 rate;
>
> if (!eemi_ops)
> return -ENXIO;
> @@ -132,6 +142,44 @@ static int process_api_request(u32 pm_id, u64 *pm_api_arg, u32 *pm_api_ret)
> pm_api_ret[2], pm_api_ret[3]);
> break;
> }
> + case PM_CLOCK_ENABLE:
> + ret = eemi_ops->clock_enable(pm_api_arg[0]);
> + break;
As I mentioned in earlier patch, I don't see the need for this debugfs
interface. Clock lay has read-only interface in debugfs already. Also if
you want to debug clocks, you can do so using the driver which uses
these clocks. Do you really want to manage clocks in user-space ?
The whole idea of EEMI kind of interface is to abstract and hide the
fine details even from non-trusted rich OS like Linux kernel, but by
providing this you are doing exactly opposite.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v6 06/11] firmware: xilinx: Add debugfs interface
From: Sudeep Holla @ 2018-05-10 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1523389127-14243-7-git-send-email-jollys@xilinx.com>
On 10/04/18 20:38, Jolly Shah wrote:
> From: Rajan Vaja <rajanv@xilinx.com>
>
> Firmware-debug provides debugfs interface to all APIs.
> Debugfs can be used to call firmware APIs with required
> parameters.
>
> Usage:
> * Calling firmware API through debugfs:
> # echo "<api-name> <arg1> .. <argn>" > /sys/.../zynqmp-firmware/pm
>
> * Read output of last called firmware API:
> # cat /sys/.../zynqmp-firmware/pm
>
> Refer ug1200 for more information on these APIs:
> * https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
>
> Add basic debugfs file to get API version.
Who are the users of this apart from debugging ? I am bit over sensitive
as this remote processor manages/controls the power and other shared
resources in the system. Giving such fine grained access to user space
is not a good idea. I assume you want this DEBUGFS off by default on
production images ?
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] ARM: dts: vexpress: Replace '_' with '-' in node names
From: Sudeep Holla @ 2018-05-10 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+csM-Z8+bMTdD7gWhWRQLAkD0EMNUS0boWkes345cCrw@mail.gmail.com>
On 10/05/18 15:05, Rob Herring wrote:
> On Thu, May 10, 2018 at 5:51 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 09/05/18 22:14, Rob Herring wrote:
>>> On Wed, May 9, 2018 at 11:48 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>> The latest DTC throws warnings for character '_' in the node names.
>>>>
>>>> Warning (node_name_chars_strict): /sysreg at 10000/sys_led: Character '_' not recommended in node name
>>>> Warning (node_name_chars_strict): /sysreg at 10000/sys_mci: Character '_' not recommended in node name
>>>> Warning (node_name_chars_strict): /sysreg at 10000/sys_flash: Character '_' not recommended in node name
>>>>
>>>> The general recommendation is to use character '-' for all the node names.
>>>> This patch fixes the warnings following the recommendation.
>>>>
>>>> Cc: Liviu Dudau <liviu.dudau@arm.com>
>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>> ---
>>>> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 6 +++---
>>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
>>>> index 7b8ff5b3b912..58e73131ecef 100644
>>>> --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
>>>> +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
>>>> @@ -77,19 +77,19 @@
>>>> compatible = "arm,vexpress-sysreg";
>>>> reg = <0x010000 0x1000>;
>>>>
>>>> - v2m_led_gpios: sys_led {
>>>> + v2m_led_gpios: sys-led {
>>>
>>> Except this is a gpio-controller so it should have 'gpio' for its node
>>> name. (I have a dtc check written for that, but there are too many
>>> false positives.)
>>>
>>
>> True, sorry I didn't look at it in detail.
>>
>>> But then you have 3 of them and no addressing, so you need to add reg
>>> property (with the register's offset and size) and unit-address.
>>>
>>
>> Indeed. I had a look at the history but couldn't gather much. All I
>> could get is that this is one of those weird mix of all functionality on
>> ARM Ltd platforms which fits no subsystem. Me and Lorenzo has similar
>> issue on TC2 platform. Pawel seem to have plumed this system control
>> registers block into MFD and GPIO long back.
>>
>>> I'm surprised Linus W accepted these a GPIO when they are not really
>>> general purpose, but then lots of things slip in.
>>>
>>
>> I assume all these happened in early days of DT.
>>
>> I will drop this for now. I will take a look if these nodes can be made
>> better to align with standard gpio controller nodes.
>
> Why not just make the changes I suggested? It shouldn't break
> anything. You can add reg property even though the kernel doesn't use
> it.
>
Ah OK. That makes sense. IIRC it used to have some @<offset> value
previously which has some correlation to HW block. I will dig that out.
Sorry I missed that you were suggesting to add reg property.
--
Regards,
Sudeep
^ permalink raw reply
* [xlnx:xlnx_rebase_v4.14 74/918] drivers/fpga/zynqmp-fpga.c:79:2: error: implicit declaration of function '__flush_cache_user_range'; did you mean 'flush_cache_range'?
From: kbuild test robot @ 2018-05-10 14:16 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/Xilinx/linux-xlnx xlnx_rebase_v4.14
head: 944a760cdb1098e23096c923aef70488fdbd501b
commit: d91b9e49c2c2663091e2d71a136ad2db919a91b3 [74/918] fpga manager: Adding FPGA Manager support for Xilinx zynqmp
config: parisc-allmodconfig (attached as .config)
compiler: hppa-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout d91b9e49c2c2663091e2d71a136ad2db919a91b3
# save the attached .config to linux build tree
make.cross ARCH=parisc
All errors (new ones prefixed by >>):
drivers/fpga/zynqmp-fpga.c: In function 'zynqmp_fpga_ops_write':
>> drivers/fpga/zynqmp-fpga.c:79:2: error: implicit declaration of function '__flush_cache_user_range'; did you mean 'flush_cache_range'? [-Werror=implicit-function-declaration]
__flush_cache_user_range((unsigned long)kbuf,
^~~~~~~~~~~~~~~~~~~~~~~~
flush_cache_range
cc1: some warnings being treated as errors
vim +79 drivers/fpga/zynqmp-fpga.c
45
46 static int zynqmp_fpga_ops_write(struct fpga_manager *mgr,
47 const char *buf, size_t size)
48 {
49 struct zynqmp_fpga_priv *priv;
50 char *kbuf;
51 size_t dma_size;
52 dma_addr_t dma_addr;
53 u32 transfer_length;
54 int ret;
55 const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
56
57 if (!eemi_ops || !eemi_ops->fpga_load)
58 return -ENXIO;
59
60 priv = mgr->priv;
61
62 if (mgr->flags & IXR_FPGA_ENCRYPTION_EN)
63 dma_size = size + ENCRYPTED_KEY_LEN + ENCRYPTED_IV_LEN;
64 else
65 dma_size = size;
66
67 kbuf = dma_alloc_coherent(priv->dev, dma_size, &dma_addr, GFP_KERNEL);
68 if (!kbuf)
69 return -ENOMEM;
70
71 memcpy(kbuf, buf, size);
72
73 if (mgr->flags & IXR_FPGA_ENCRYPTION_EN) {
74 memcpy(kbuf + size, mgr->key, ENCRYPTED_KEY_LEN);
75 memcpy(kbuf + size + ENCRYPTED_KEY_LEN, mgr->iv,
76 ENCRYPTED_IV_LEN);
77 }
78
> 79 __flush_cache_user_range((unsigned long)kbuf,
80 (unsigned long)kbuf + dma_size);
81
82 /**
83 * Translate size from bytes to number of 32bit words that
84 * the DMA should write to the PCAP interface
85 */
86 if (size & 3)
87 transfer_length = (size >> 2) + 1;
88 else
89 transfer_length = size >> 2;
90
91 ret = eemi_ops->fpga_load(dma_addr, transfer_length, mgr->flags);
92
93 dma_free_coherent(priv->dev, dma_size, kbuf, dma_addr);
94
95 return ret;
96 }
97
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 51306 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180510/b0870d2f/attachment-0001.gz>
^ permalink raw reply
* [RFC 00/13] arm: Allow the user specifying where the RAM is place in the memory
From: Julien Grall @ 2018-05-10 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510140441.24573-1-julien.grall@arm.com>
I forgot to mention in the title that the series is for kvmtools. Sorry
for the confusion.
Cheers,
On 10/05/18 15:04, Julien Grall wrote:
> Hi all,
>
> At the moment, a user is only able to specify the amount of RAM used by the
> guest. Where the RAM will live is left to the software and hardcoded.
>
> It could be useful for testing purpose to move the RAM in different place.
> This series adds the possibility for the user to specify multiple RAM region.
>
> The option -m/--mem is extended to specify the address using the following
> format: <size>@<addr>. The option needs to be repeated as many times as the
> number of RAM region in the guest layout.
>
> For instance, if you want 512MB at 3GB and 512MB 4GB it would look like:
> -m 512 at 0xc0000000 -m 512 at 0x100000000
>
> Note that the memory layout is not yet fully configurable by the user, so the
> MMIO region is still living below 2GB. This means RAM cannot live in the
> region 0-2GB. This could be changed in the future.
>
> This new version also integrates work from Suzuki to allow the user specifying
> the IPA size for the guest. This was previously sent separately on kvmarm [1].
>
> Cheers,
>
> [1] https://lkml.org/lkml/2018/3/27/437
>
> Julien Grall (7):
> kvm__arch_init: Don't pass hugetlbfs_path and ram_size in parameter
> virtio/scsi: Allow to use multiple banks
> Fold kvm__init_ram call in kvm__arch_init
> kvm__arch_sanitize_cfg
> arm: Move anything related to RAM initialization in kvm__init_ram
> Allow the user to specify where the RAM is placed in the memory
> arm: Add support for multi memory regions
>
> Suzuki K Poulose (6):
> arm: Allow use of hugepage with 16K pagesize host
> virtio: Handle aborts using invalid PFN
> kvmtool: Allow backends to run checks on the KVM device fd
> kvmtool: arm64: Add support for guest physical address size
> kvmtool: arm64: Switch memory layout
> kvmtool: arm/arm64: Add support for creating VM with PA size
>
> arm/aarch32/include/kvm/kvm-arch.h | 3 +-
> arm/aarch64/include/kvm/kvm-arch.h | 15 ++-
> arm/aarch64/include/kvm/kvm-config-arch.h | 5 +-
> arm/fdt.c | 17 ++-
> arm/include/arm-common/kvm-arch.h | 32 ++++--
> arm/include/arm-common/kvm-config-arch.h | 1 +
> arm/kvm.c | 183 +++++++++++++++++++++++++-----
> builtin-run.c | 87 ++++++++++++--
> include/kvm/kvm-config.h | 16 ++-
> include/kvm/kvm.h | 28 ++++-
> kvm.c | 10 +-
> mips/kvm.c | 47 +++++---
> powerpc/kvm.c | 33 +++---
> virtio/mmio.c | 14 ++-
> virtio/pci.c | 10 +-
> virtio/scsi.c | 21 ++--
> x86/bios.c | 8 +-
> x86/kvm.c | 54 +++++----
> 18 files changed, 443 insertions(+), 141 deletions(-)
>
--
Julien Grall
^ permalink raw reply
* [PATCH v6 04/11] firmware: xilinx: Add query data API
From: Sudeep Holla @ 2018-05-10 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1523389127-14243-5-git-send-email-jollys@xilinx.com>
On 10/04/18 20:38, Jolly Shah wrote:
> From: Rajan Vaja <rajanv@xilinx.com>
>
> Add ZynqMP firmware query data API to query platform
> specific information(clocks, pins) from firmware.
>
> Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> Signed-off-by: Jolly Shah <jollys@xilinx.com>
> ---
> drivers/firmware/xilinx/zynqmp.c | 14 ++++++++++++++
> include/linux/firmware/xlnx-zynqmp.h | 20 ++++++++++++++++++++
> 2 files changed, 34 insertions(+)
>
> diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
> index 44b43fa..ef09c44 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -258,9 +258,23 @@ static int zynqmp_pm_ioctl(u32 node_id, u32 ioctl_id, u32 arg1, u32 arg2,
> arg1, arg2, out);
> }
>
> +/**
> + * zynqmp_pm_query_data() - Get query data from firmware
> + * @qdata: Variable to the zynqmp_pm_query_data structure
> + * @out: Returned output value
> + *
> + * Return: Returns status, either success or error+reason
> + */
> +static int zynqmp_pm_query_data(struct zynqmp_pm_query_data qdata, u32 *out)
> +{
> + return zynqmp_pm_invoke_fn(PM_QUERY_DATA, qdata.qid, qdata.arg1,
> + qdata.arg2, qdata.arg3, out);
> +}
> +
> static const struct zynqmp_eemi_ops eemi_ops = {
> .get_api_version = zynqmp_pm_get_api_version,
> .ioctl = zynqmp_pm_ioctl,
> + .query_data = zynqmp_pm_query_data,
Can you give more insight into this ? How will be this used ?
How this aligns with data we get from DT ? I am just trying to
understand how is this information split between this API and DT for
example.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH]irqchip/irq-gic-v3:Avoid a waste of LPI resource
From: Marc Zyngier @ 2018-05-10 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8898674D84E3B24BA3A2D289B872026A69F09954@G01JPEXMBKW03>
Hi Lei,
On 10/05/18 14:09, Zhang, Lei wrote:
> Hi Mark, Marc
>
>> -----Original Message-----
>> From: linux-arm-kernel
>> [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of
>> Mark Langsdorf
>> Sent: Wednesday, May 09, 2018 11:32 PM
>> To: linux-arm-kernel at lists.infradead.org
>> Subject: Re: [PATCH]irqchip/irq-gic-v3:Avoid a waste of LPI resource
>>
>
>> Marc's suggestion of implementing a glue layer, and then changing the
>> glue layer interface to pass the allocation requirements up to this
>> driver is the best solution that can be supported for server products.
>
> Thanks for your comments.
> ?
> I'm considering implementing a glue layer. But the management of
> whole LPI resource is implemented by core ITS driver (irq-gic-v3-its.c),
> So I think core ITS driver also need to be modified.
> ?
> Below is my idea for core ITS driver.
> Would you give me comments?
> ?
> Add an interface that can specify the number of LPIs allocation requirements on Core ITS driver.
> My idea is extend its_msi_prepare function by adding two argument.
>
> SYNOPSIS
> its_msi_prepare(struct irq_domain *domain, struct device *dev,int nvec,
> msi_alloc_info_t *info,int request_nr_lpis, int request_lpis_align)
> ?
> Argument "request_nr_lpis" means request LPIs total number for device.
I do not believe this is required. nvec already describes the number of
LPIs that are expected by the device. Why should we add a new parameter
that looks to be the exact same thing?
> Argument "request_lpis_align" means request of LPIs alignment. 0 means do not specify alignment.
Another problem is that this approach isn't really practical.
msi_prepare is part of a generic structure, and changing it will impact
all the others users of that structure. I'd rather you don't change its
prototype for something that is implementation specific.
Instead, we have the msi_alloc_info_t structure, which is explicitly
designed to collate information pertaining to the allocation
requirements in an implementation agnostic way.
At the moment, the ITS code only uses the first entry of the scratchpad
area to store the DeviceID (and subsequently a pointer to the
corresponding its_device).
You could use the second entry to encode the alignment requirement.
> For PCI, PCI glue layer specifies, request_nr_lpis = 32, request_lpis_align = 32.
> For our device, the glue layer specifies, request_nr_lpis = 1, request_lpis_align = 0.
> (We have lots of device but each device only need a single LPI on our original bus. )
> ?
>
> For expanding two arguments, core ITS driver maybe need to discard chunk mechanism
> and use bitmap to manage LPI resource directly.
> ?
> Example:
> (1) Non PCI glue layer requires ?request_nr_lpis? = 1, ?request_lpis_align? = 0.
> ?
> Bitmap will become ...0000000000000000001
> ?
> (2) PCI glue layer requires ?request_nr_lpis? = 32, ?request_lpis_align? = 32.
> ?
> Bitmap will become ...000FFFFFFFF00000001
> ?
> ?
> (3) Non PCI glue layer requires ?request_nr_lpis? = 1, ?request_lpis_align? = 0.
> ?
> Bitmap will become ...000FFFFFFFF00000003
> ?> I think it may be easy to implement by using
> bitmap_find_next_zero_area, because it has ?align_mask? argument.
The problem is that you now increase the footprint of the bitmap by a
factor of 32:
- For a system with 16bit INTIDs, you go from 256 bytes to 8kB. That's
bad, but OK, fine.
- For a system with 32bit INTIDs, you go from 16MB (which was already
horrible) to 512MB. That's unacceptable.
At that point, using a simple bitmap doesn't work anymore, and we're
better off switching to a free list of some sort that would keep the
memory overhead to a minimum (and actually radically reduce the
footprint even in the smallest configurations).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v6 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control
From: Sudeep Holla @ 2018-05-10 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1523389127-14243-4-git-send-email-jollys@xilinx.com>
On 10/04/18 20:38, Jolly Shah wrote:
> From: Rajan Vaja <rajanv@xilinx.com>
>
> Add ZynqMP firmware IOCTL API to control and configure
> devices like PLLs, SD, Gem, etc.
>
> Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> Signed-off-by: Jolly Shah <jollys@xilinx.com>
> ---
> drivers/firmware/xilinx/zynqmp.c | 20 ++++++++++++++++++++
> include/linux/firmware/xlnx-zynqmp.h | 2 ++
> 2 files changed, 22 insertions(+)
>
> diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
> index 490561a..44b43fa 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -239,8 +239,28 @@ static int get_set_conduit_method(struct device_node *np)
> return 0;
> }
>
> +/**
> + * zynqmp_pm_ioctl() - PM IOCTL API for device control and configs
> + * @node_id: Node ID of the device
> + * @ioctl_id: ID of the requested IOCTL
> + * @arg1: Argument 1 to requested IOCTL call
> + * @arg2: Argument 2 to requested IOCTL call
> + * @out: Returned output value
> + *
> + * This function calls IOCTL to firmware for device control and configuration.
> + *
> + * Return: Returns status, either success or error+reason
> + */
> +static int zynqmp_pm_ioctl(u32 node_id, u32 ioctl_id, u32 arg1, u32 arg2,
> + u32 *out)
> +{
> + return zynqmp_pm_invoke_fn(PM_IOCTL, node_id, ioctl_id,
> + arg1, arg2, out);
> +}
> +
> static const struct zynqmp_eemi_ops eemi_ops = {
> .get_api_version = zynqmp_pm_get_api_version,
> + .ioctl = zynqmp_pm_ioctl,
> };
>
> /**
> diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
> index cb63bed..2eec6e7 100644
> --- a/include/linux/firmware/xlnx-zynqmp.h
> +++ b/include/linux/firmware/xlnx-zynqmp.h
> @@ -34,6 +34,7 @@
>
> enum pm_api_id {
> PM_GET_API_VERSION = 1,
> + PM_IOCTL = 34,
I am not for this API. IIUC there are more fined grained well defined
APIs(if I am not wrong from enum 2 upto 33). This is open ended API
which allows user to do whatever setting it needs. And that defeats the
purpose of other APIs.
I will look through the series for the usage of this to understand this
better, but I am guessing how it can be (ab)used.
--
Regards,
Sudeep
^ permalink raw reply
* [xlnx:xlnx_rebase_v4.14 730/918] drivers/crypto/zynqmp-sha.c:133:3: error: implicit declaration of function '__flush_cache_user_range'; did you mean 'flush_cache_range'?
From: kbuild test robot @ 2018-05-10 14:08 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/Xilinx/linux-xlnx xlnx_rebase_v4.14
head: 944a760cdb1098e23096c923aef70488fdbd501b
commit: 5cccc03f86f27a3e9e76ba7a863eaf2f8506e9e2 [730/918] crypto: zynqmp: Use new firmware ops
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 5cccc03f86f27a3e9e76ba7a863eaf2f8506e9e2
# save the attached .config to linux build tree
make.cross ARCH=sh
All errors (new ones prefixed by >>):
drivers/crypto/zynqmp-sha.c: In function 'zynqmp_sha_update':
>> drivers/crypto/zynqmp-sha.c:133:3: error: implicit declaration of function '__flush_cache_user_range'; did you mean 'flush_cache_range'? [-Werror=implicit-function-declaration]
__flush_cache_user_range((unsigned long)kbuf,
^~~~~~~~~~~~~~~~~~~~~~~~
flush_cache_range
cc1: some warnings being treated as errors
vim +133 drivers/crypto/zynqmp-sha.c
3abec383 Nava kishore Manne 2017-09-19 111
3abec383 Nava kishore Manne 2017-09-19 112 static int zynqmp_sha_update(struct ahash_request *req)
3abec383 Nava kishore Manne 2017-09-19 113 {
3abec383 Nava kishore Manne 2017-09-19 114 struct zynqmp_sha_ctx *tctx = crypto_tfm_ctx(req->base.tfm);
3abec383 Nava kishore Manne 2017-09-19 115 struct zynqmp_sha_dev *dd = tctx->dd;
5cccc03f Rajan Vaja 2018-03-01 116 const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
3abec383 Nava kishore Manne 2017-09-19 117 char *kbuf;
3abec383 Nava kishore Manne 2017-09-19 118 size_t dma_size = req->nbytes;
3abec383 Nava kishore Manne 2017-09-19 119 dma_addr_t dma_addr;
3abec383 Nava kishore Manne 2017-09-19 120 int ret;
3abec383 Nava kishore Manne 2017-09-19 121
3abec383 Nava kishore Manne 2017-09-19 122 if (!req->nbytes)
3abec383 Nava kishore Manne 2017-09-19 123 return 0;
3abec383 Nava kishore Manne 2017-09-19 124
5cccc03f Rajan Vaja 2018-03-01 125 if (!eemi_ops || !eemi_ops->sha_hash)
5cccc03f Rajan Vaja 2018-03-01 126 return -ENOTSUPP;
5cccc03f Rajan Vaja 2018-03-01 127
3abec383 Nava kishore Manne 2017-09-19 128 kbuf = dma_alloc_coherent(dd->dev, dma_size, &dma_addr, GFP_KERNEL);
3abec383 Nava kishore Manne 2017-09-19 129 if (!kbuf)
3abec383 Nava kishore Manne 2017-09-19 130 return -ENOMEM;
3abec383 Nava kishore Manne 2017-09-19 131
3abec383 Nava kishore Manne 2017-09-19 132 scatterwalk_map_and_copy(kbuf, req->src, 0, req->nbytes, 0);
3abec383 Nava kishore Manne 2017-09-19 @133 __flush_cache_user_range((unsigned long)kbuf,
3abec383 Nava kishore Manne 2017-09-19 134 (unsigned long)kbuf + dma_size);
5cccc03f Rajan Vaja 2018-03-01 135 ret = eemi_ops->sha_hash(dma_addr, req->nbytes, ZYNQMP_SHA3_UPDATE);
3abec383 Nava kishore Manne 2017-09-19 136 dma_free_coherent(dd->dev, dma_size, kbuf, dma_addr);
3abec383 Nava kishore Manne 2017-09-19 137
3abec383 Nava kishore Manne 2017-09-19 138 return ret;
3abec383 Nava kishore Manne 2017-09-19 139 }
3abec383 Nava kishore Manne 2017-09-19 140
:::::: The code at line 133 was first introduced by commit
:::::: 3abec3839538ef5fe79c2873360d84cc92b4df25 crypto: zynqmp-sha: Adopted SHA3 support for ZynqMP Soc
:::::: TO: Nava kishore Manne <nava.manne@xilinx.com>
:::::: CC: Michal Simek <michal.simek@xilinx.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 46832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180510/97981c60/attachment-0001.gz>
^ permalink raw reply
* [PATCH] ARM: dts: vexpress: Replace '_' with '-' in node names
From: Rob Herring @ 2018-05-10 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f28fb5d6-1070-8cbb-e815-4baf7128b19e@arm.com>
On Thu, May 10, 2018 at 5:51 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 09/05/18 22:14, Rob Herring wrote:
>> On Wed, May 9, 2018 at 11:48 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> The latest DTC throws warnings for character '_' in the node names.
>>>
>>> Warning (node_name_chars_strict): /sysreg at 10000/sys_led: Character '_' not recommended in node name
>>> Warning (node_name_chars_strict): /sysreg at 10000/sys_mci: Character '_' not recommended in node name
>>> Warning (node_name_chars_strict): /sysreg at 10000/sys_flash: Character '_' not recommended in node name
>>>
>>> The general recommendation is to use character '-' for all the node names.
>>> This patch fixes the warnings following the recommendation.
>>>
>>> Cc: Liviu Dudau <liviu.dudau@arm.com>
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>> ---
>>> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 6 +++---
>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
>>> index 7b8ff5b3b912..58e73131ecef 100644
>>> --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
>>> +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
>>> @@ -77,19 +77,19 @@
>>> compatible = "arm,vexpress-sysreg";
>>> reg = <0x010000 0x1000>;
>>>
>>> - v2m_led_gpios: sys_led {
>>> + v2m_led_gpios: sys-led {
>>
>> Except this is a gpio-controller so it should have 'gpio' for its node
>> name. (I have a dtc check written for that, but there are too many
>> false positives.)
>>
>
> True, sorry I didn't look at it in detail.
>
>> But then you have 3 of them and no addressing, so you need to add reg
>> property (with the register's offset and size) and unit-address.
>>
>
> Indeed. I had a look at the history but couldn't gather much. All I
> could get is that this is one of those weird mix of all functionality on
> ARM Ltd platforms which fits no subsystem. Me and Lorenzo has similar
> issue on TC2 platform. Pawel seem to have plumed this system control
> registers block into MFD and GPIO long back.
>
>> I'm surprised Linus W accepted these a GPIO when they are not really
>> general purpose, but then lots of things slip in.
>>
>
> I assume all these happened in early days of DT.
>
> I will drop this for now. I will take a look if these nodes can be made
> better to align with standard gpio controller nodes.
Why not just make the changes I suggested? It shouldn't break
anything. You can add reg property even though the kernel doesn't use
it.
Rob
^ permalink raw reply
* [PATCH v6 02/11] firmware: xilinx: Add Zynqmp firmware driver
From: Sudeep Holla @ 2018-05-10 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1523389127-14243-3-git-send-email-jollys@xilinx.com>
On 10/04/18 20:38, Jolly Shah wrote:
> From: Rajan Vaja <rajanv@xilinx.com>
>
> This patch is adding communication layer with firmware.
> Firmware driver provides an interface to firmware APIs.
> Interface APIs can be used by any driver to communicate to
> PMUFW(Platform Management Unit). All requests go through ATF.
>
> Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> Signed-off-by: Jolly Shah <jollys@xilinx.com>
> ---
[...]
> +
> +/**
> + * get_set_conduit_method() - Choose SMC or HVC based communication
> + * @np: Pointer to the device_node structure
> + *
> + * Use SMC or HVC-based functions to communicate with EL2/EL3.
> + *
> + * Return: Returns 0 on success or error code
> + */
> +static int get_set_conduit_method(struct device_node *np)
> +{
> + const char *method;
> +
> + if (of_property_read_string(np, "method", &method)) {
> + pr_warn("%s missing \"method\" property\n", __func__);
> + return -ENXIO;
> + }
> +
> + if (!strcmp("hvc", method)) {
> + do_fw_call = do_fw_call_hvc;
> + } else if (!strcmp("smc", method)) {
> + do_fw_call = do_fw_call_smc;
> + } else {
> + pr_warn("%s Invalid \"method\" property: %s\n",
> + __func__, method);
> + return -EINVAL;
> + }
> +
Mark R did some cleanup around SMCCC conduits[1]. It makes sense to base
this on top that. But if you manage to push this for v4.18, then you may
need to wait for that to be merged and clean it up after v4.18
--
Regards,
Sudeep
[1] https://www.spinics.net/lists/arm-kernel/msg650305.html
^ permalink raw reply
* [RFC 13/13] kvmtool: arm/arm64: Add support for creating VM with PA size
From: Julien Grall @ 2018-05-10 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510140441.24573-1-julien.grall@arm.com>
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Specify the physical size for the VM encoded in the vm type.
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Julien Grall <julien.grall@arm.com>
[julien: Don't specify the type of older kernels | fix max_ipa type]
---
arm/include/arm-common/kvm-arch.h | 6 +++++-
arm/kvm.c | 27 +++++++++++++++++++++++++++
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/arm/include/arm-common/kvm-arch.h b/arm/include/arm-common/kvm-arch.h
index 4be9589..81be262 100644
--- a/arm/include/arm-common/kvm-arch.h
+++ b/arm/include/arm-common/kvm-arch.h
@@ -46,7 +46,11 @@
#define KVM_IRQ_OFFSET GIC_SPI_IRQ_BASE
-#define KVM_VM_TYPE 0
+extern unsigned long kvm_arm_type;
+extern void kvm__arch_init_hyp(struct kvm *kvm);
+
+#define KVM_VM_TYPE kvm_arm_type
+#define kvm__arch_init_hyp kvm__arch_init_hyp
#define VIRTIO_DEFAULT_TRANS(kvm) \
((kvm)->cfg.arch.virtio_trans_pci ? VIRTIO_PCI : VIRTIO_MMIO)
diff --git a/arm/kvm.c b/arm/kvm.c
index 5a2bd28..97c1333 100644
--- a/arm/kvm.c
+++ b/arm/kvm.c
@@ -13,6 +13,8 @@
#include <stdlib.h>
+unsigned long kvm_arm_type;
+
struct kvm_ext kvm_req_ext[] = {
{ DEFINE_KVM_EXT(KVM_CAP_IRQCHIP) },
{ DEFINE_KVM_EXT(KVM_CAP_ONE_REG) },
@@ -20,6 +22,31 @@ struct kvm_ext kvm_req_ext[] = {
{ 0, 0 },
};
+#ifndef KVM_ARM_GET_MAX_VM_PHYS_SHIFT
+#define KVM_ARM_GET_MAX_VM_PHYS_SHIFT _IO(KVMIO, 0x0a)
+#endif
+
+void kvm__arch_init_hyp(struct kvm *kvm)
+{
+ int max_ipa;
+
+ max_ipa = ioctl(kvm->sys_fd, KVM_ARM_GET_MAX_VM_PHYS_SHIFT);
+ if (max_ipa < 0)
+ max_ipa = 40;
+ if (!kvm->cfg.arch.phys_shift)
+ kvm->cfg.arch.phys_shift = 40;
+ if (kvm->cfg.arch.phys_shift > max_ipa)
+ die("Requested PA size (%u) is not supported by the host (%ubits)\n",
+ kvm->cfg.arch.phys_shift, max_ipa);
+
+ /*
+ * Kernel not implementing the ioctl KVM_ARM_GET_MAX_VM_PHYS_SHIFT
+ * will request to have kvm_arm_type zeroed and assume 40 bits IPA.
+ */
+ if (kvm->cfg.arch.phys_shift != 40)
+ kvm_arm_type = kvm->cfg.arch.phys_shift;
+}
+
bool kvm__arch_cpu_supports_vm(void)
{
/* The KVM capability check is enough. */
--
2.11.0
^ permalink raw reply related
* [RFC 12/13] kvmtool: arm64: Switch memory layout
From: Julien Grall @ 2018-05-10 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510140441.24573-1-julien.grall@arm.com>
From: Suzuki K Poulose <suzuki.poulose@arm.com>
If the guest wants to use a larger physical address space place
the RAM at upper half of the address space. Otherwise, it uses the
default layout.
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arm/aarch32/include/kvm/kvm-arch.h | 1 +
arm/aarch64/include/kvm/kvm-arch.h | 13 ++++++++++---
arm/include/arm-common/kvm-arch.h | 8 ++++++--
arm/kvm.c | 2 +-
4 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h
index 2ee0cb1..f0f0943 100644
--- a/arm/aarch32/include/kvm/kvm-arch.h
+++ b/arm/aarch32/include/kvm/kvm-arch.h
@@ -4,6 +4,7 @@
#define ARM_KERN_OFFSET(...) 0x8000
#define ARM_MAX_PHYS_SHIFT(...) 32
+#define ARM_MEMORY_AREA(...) ARM32_MEMORY_AREA
#include "arm-common/kvm-arch.h"
diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h
index 53ac20f..9c9009b 100644
--- a/arm/aarch64/include/kvm/kvm-arch.h
+++ b/arm/aarch64/include/kvm/kvm-arch.h
@@ -1,12 +1,19 @@
#ifndef KVM__KVM_ARCH_H
#define KVM__KVM_ARCH_H
+#include "arm-common/kvm-arch.h"
+
+#define ARM64_MEMORY_AREA(phys_shift) (1UL << (phys_shift - 1))
+
+#define ARM_MEMORY_AREA(cfg) ((cfg)->arch.aarch32_guest ? \
+ ARM32_MEMORY_AREA : \
+ ARM64_MEMORY_AREA((cfg)->arch.phys_shift))
+
#define ARM_KERN_OFFSET(kvm) ((kvm)->cfg.arch.aarch32_guest ? \
0x8000 : \
0x80000)
-#define ARM_MAX_PHYS_SHIFT(cfg) ((cfg)->arch.aarch32_guest ? 32 : 40)
-
-#include "arm-common/kvm-arch.h"
+#define ARM_MAX_PHYS_SHIFT(cfg) ((cfg)->arch.aarch32_guest ? 32 : \
+ (cfg)->arch.phys_shift)
#endif /* KVM__KVM_ARCH_H */
diff --git a/arm/include/arm-common/kvm-arch.h b/arm/include/arm-common/kvm-arch.h
index 884dda8..4be9589 100644
--- a/arm/include/arm-common/kvm-arch.h
+++ b/arm/include/arm-common/kvm-arch.h
@@ -10,7 +10,11 @@
#define ARM_IOPORT_AREA _AC(0x0000000000000000, UL)
#define ARM_MMIO_AREA _AC(0x0000000000010000, UL)
#define ARM_AXI_AREA _AC(0x0000000040000000, UL)
-#define ARM_MEMORY_AREA _AC(0x0000000080000000, UL)
+
+#define ARM32_MEMORY_AREA _AC(0x0000000080000000, UL)
+#define ARM32_MAX_MEMORY ((1ULL << 32) - ARM32_MEMORY_AREA)
+
+#define ARM_IOMEM_AREA_END ARM32_MEMORY_AREA
#define ARM_GIC_DIST_BASE (ARM_AXI_AREA - ARM_GIC_DIST_SIZE)
#define ARM_GIC_CPUI_BASE (ARM_GIC_DIST_BASE - ARM_GIC_CPUI_SIZE)
@@ -21,7 +25,7 @@
#define ARM_IOPORT_SIZE (ARM_MMIO_AREA - ARM_IOPORT_AREA)
#define ARM_VIRTIO_MMIO_SIZE (ARM_AXI_AREA - (ARM_MMIO_AREA + ARM_GIC_SIZE))
#define ARM_PCI_CFG_SIZE (1ULL << 24)
-#define ARM_PCI_MMIO_SIZE (ARM_MEMORY_AREA - \
+#define ARM_PCI_MMIO_SIZE (ARM_IOMEM_AREA_END - \
(ARM_AXI_AREA + ARM_PCI_CFG_SIZE))
#define KVM_IOPORT_AREA ARM_IOPORT_AREA
diff --git a/arm/kvm.c b/arm/kvm.c
index 8a7c611..5a2bd28 100644
--- a/arm/kvm.c
+++ b/arm/kvm.c
@@ -127,7 +127,7 @@ static void kvm__arch_sanitize_cfg(struct kvm_config *cfg)
*/
if (cfg->nr_ram > 1)
die("sanitize: Base address should be specified for all the banks\n");
- bank0->base = ARM_MEMORY_AREA;
+ bank0->base = ARM_MEMORY_AREA(cfg);
/*
* Keep compatibility with old KVM command line behavior where
* the memory is capped.
--
2.11.0
^ permalink raw reply related
* [RFC 11/13] kvmtool: arm64: Add support for guest physical address size
From: Julien Grall @ 2018-05-10 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510140441.24573-1-julien.grall@arm.com>
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Add an option to specify the physical address size used by this
VM.
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arm/aarch64/include/kvm/kvm-config-arch.h | 5 ++++-
arm/include/arm-common/kvm-config-arch.h | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h b/arm/aarch64/include/kvm/kvm-config-arch.h
index 04be43d..c4bb207 100644
--- a/arm/aarch64/include/kvm/kvm-config-arch.h
+++ b/arm/aarch64/include/kvm/kvm-config-arch.h
@@ -8,7 +8,10 @@
"Create PMUv3 device"), \
OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed, \
"Specify random seed for Kernel Address Space " \
- "Layout Randomization (KASLR)"),
+ "Layout Randomization (KASLR)"), \
+ OPT_UINTEGER('\0', "phys-shift", &(cfg)->phys_shift, \
+ "Specify maximum physical address size (not " \
+ "the amount of memory)"),
#include "arm-common/kvm-config-arch.h"
diff --git a/arm/include/arm-common/kvm-config-arch.h b/arm/include/arm-common/kvm-config-arch.h
index 6a196f1..d841b0b 100644
--- a/arm/include/arm-common/kvm-config-arch.h
+++ b/arm/include/arm-common/kvm-config-arch.h
@@ -11,6 +11,7 @@ struct kvm_config_arch {
bool has_pmuv3;
u64 kaslr_seed;
enum irqchip_type irqchip;
+ unsigned int phys_shift;
};
int irqchip_parser(const struct option *opt, const char *arg, int unset);
--
2.11.0
^ permalink raw reply related
* [RFC 10/13] kvmtool: Allow backends to run checks on the KVM device fd
From: Julien Grall @ 2018-05-10 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510140441.24573-1-julien.grall@arm.com>
From: Suzuki K Poulose <suzuki.poulose@arm.com>
Allow architectures to perform initialisation based on the
KVM device fd ioctls, even before the VM is created.
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
include/kvm/kvm.h | 4 ++++
kvm.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/include/kvm/kvm.h b/include/kvm/kvm.h
index 4e21446..bc916ea 100644
--- a/include/kvm/kvm.h
+++ b/include/kvm/kvm.h
@@ -107,6 +107,10 @@ int kvm__get_sock_by_instance(const char *name);
int kvm__enumerate_instances(int (*callback)(const char *name, int pid));
void kvm__remove_socket(const char *name);
+#ifndef kvm__arch_init_hyp
+static inline void kvm__arch_init_hyp(struct kvm *kvm) {}
+#endif
+
void kvm__arch_set_cmdline(char *cmdline, bool video);
void kvm__arch_init(struct kvm *kvm);
void kvm__arch_delete_ram(struct kvm *kvm);
diff --git a/kvm.c b/kvm.c
index 9c2cb2f..f40975b 100644
--- a/kvm.c
+++ b/kvm.c
@@ -308,6 +308,8 @@ int kvm__init(struct kvm *kvm)
goto err_sys_fd;
}
+ kvm__arch_init_hyp(kvm);
+
kvm->vm_fd = ioctl(kvm->sys_fd, KVM_CREATE_VM, KVM_VM_TYPE);
if (kvm->vm_fd < 0) {
pr_err("KVM_CREATE_VM ioctl");
--
2.11.0
^ permalink raw reply related
* [RFC 09/13] virtio: Handle aborts using invalid PFN
From: Julien Grall @ 2018-05-10 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510140441.24573-1-julien.grall@arm.com>
From: Suzuki K Poulose <suzuki.poulose@arm.com>
When the host fails to complete the shake hand due to various
reasons. e.g, for PCI and MMIO, if 0 is written as the PFN,
it implies the host has given up and simply don't take any
action.
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
virtio/mmio.c | 14 ++++++++------
virtio/pci.c | 10 ++++++----
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/virtio/mmio.c b/virtio/mmio.c
index 8c0f1cc..b118b8a 100644
--- a/virtio/mmio.c
+++ b/virtio/mmio.c
@@ -188,12 +188,14 @@ static void virtio_mmio_config_out(struct kvm_cpu *vcpu,
break;
case VIRTIO_MMIO_QUEUE_PFN:
val = ioport__read32(data);
- virtio_mmio_init_ioeventfd(vmmio->kvm, vdev, vmmio->hdr.queue_sel);
- vdev->ops->init_vq(vmmio->kvm, vmmio->dev,
- vmmio->hdr.queue_sel,
- vmmio->hdr.guest_page_size,
- vmmio->hdr.queue_align,
- val);
+ if (val) {
+ virtio_mmio_init_ioeventfd(vmmio->kvm, vdev, vmmio->hdr.queue_sel);
+ vdev->ops->init_vq(vmmio->kvm, vmmio->dev,
+ vmmio->hdr.queue_sel,
+ vmmio->hdr.guest_page_size,
+ vmmio->hdr.queue_align,
+ val);
+ }
break;
case VIRTIO_MMIO_QUEUE_NOTIFY:
val = ioport__read32(data);
diff --git a/virtio/pci.c b/virtio/pci.c
index 5a5fc6e..403063f 100644
--- a/virtio/pci.c
+++ b/virtio/pci.c
@@ -269,10 +269,12 @@ static bool virtio_pci__io_out(struct ioport *ioport, struct kvm_cpu *vcpu, u16
break;
case VIRTIO_PCI_QUEUE_PFN:
val = ioport__read32(data);
- virtio_pci__init_ioeventfd(kvm, vdev, vpci->queue_selector);
- vdev->ops->init_vq(kvm, vpci->dev, vpci->queue_selector,
- 1 << VIRTIO_PCI_QUEUE_ADDR_SHIFT,
- VIRTIO_PCI_VRING_ALIGN, val);
+ if (val) {
+ virtio_pci__init_ioeventfd(kvm, vdev, vpci->queue_selector);
+ vdev->ops->init_vq(kvm, vpci->dev, vpci->queue_selector,
+ 1 << VIRTIO_PCI_QUEUE_ADDR_SHIFT,
+ VIRTIO_PCI_VRING_ALIGN, val);
+ }
break;
case VIRTIO_PCI_QUEUE_SEL:
vpci->queue_selector = ioport__read16(data);
--
2.11.0
^ permalink raw reply related
* [RFC 08/13] arm: Add support for multi memory regions
From: Julien Grall @ 2018-05-10 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510140441.24573-1-julien.grall@arm.com>
Currently, the RAM will always be contiguous and start 2GB. This patch
is giving the possibility to the user to specificy multiple RAM region
and
Note that at the moment it is not possible to place any RAM region below
2GB as the MMIO region is still static.
The implementation for multi memory regions is fairly straight-forward,
althought it the following points are worth to be mention:
- The banks are sorted by base address, so it is easier to fetch the
lowest bank later on and do sanity checking
- If the user does not specify the address of the first bank, the
old behavior is kept.
Signed-off-by: Julien Grall <julien.grall@arm.com>
---
arm/aarch32/include/kvm/kvm-arch.h | 2 +-
arm/aarch64/include/kvm/kvm-arch.h | 4 +-
arm/fdt.c | 17 +++--
arm/include/arm-common/kvm-arch.h | 20 ++++--
arm/kvm.c | 125 ++++++++++++++++++++++++++++---------
5 files changed, 125 insertions(+), 43 deletions(-)
diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h
index cd31e72..2ee0cb1 100644
--- a/arm/aarch32/include/kvm/kvm-arch.h
+++ b/arm/aarch32/include/kvm/kvm-arch.h
@@ -3,7 +3,7 @@
#define ARM_KERN_OFFSET(...) 0x8000
-#define ARM_MAX_MEMORY(...) ARM_LOMAP_MAX_MEMORY
+#define ARM_MAX_PHYS_SHIFT(...) 32
#include "arm-common/kvm-arch.h"
diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h
index 1b3d0a5..53ac20f 100644
--- a/arm/aarch64/include/kvm/kvm-arch.h
+++ b/arm/aarch64/include/kvm/kvm-arch.h
@@ -5,9 +5,7 @@
0x8000 : \
0x80000)
-#define ARM_MAX_MEMORY(cfg) ((cfg)->arch.aarch32_guest ? \
- ARM_LOMAP_MAX_MEMORY : \
- ARM_HIMAP_MAX_MEMORY)
+#define ARM_MAX_PHYS_SHIFT(cfg) ((cfg)->arch.aarch32_guest ? 32 : 40)
#include "arm-common/kvm-arch.h"
diff --git a/arm/fdt.c b/arm/fdt.c
index 6ac0b33..add9dea 100644
--- a/arm/fdt.c
+++ b/arm/fdt.c
@@ -114,10 +114,7 @@ static int setup_fdt(struct kvm *kvm)
{
struct device_header *dev_hdr;
u8 staging_fdt[FDT_MAX_SIZE];
- u64 mem_reg_prop[] = {
- cpu_to_fdt64(kvm->arch.memory_guest_start),
- cpu_to_fdt64(kvm->ram[0].size),
- };
+ fdt64_t mem_reg_prop[2 * MAX_RAM_BANKS];
struct psci_fns *fns;
void *fdt = staging_fdt;
void *fdt_dest = guest_flat_to_host(kvm,
@@ -126,6 +123,8 @@ static int setup_fdt(struct kvm *kvm)
void (*)(void *, u8, enum irq_type));
void (*generate_cpu_peripheral_fdt_nodes)(void *, struct kvm *)
= kvm->cpus[0]->generate_fdt_nodes;
+ unsigned int i;
+ const struct kvm_config *cfg = &kvm->cfg;
/* Create new tree without a reserve map */
_FDT(fdt_create(fdt, FDT_MAX_SIZE));
@@ -158,9 +157,17 @@ static int setup_fdt(struct kvm *kvm)
_FDT(fdt_end_node(fdt));
/* Memory */
+ for (i = 0; i < cfg->nr_ram; i++) {
+ fdt64_t *reg = &mem_reg_prop[i * 2];
+
+ reg[0] = cpu_to_fdt64(cfg->ram[i].base);
+ reg[1] = cpu_to_fdt64(cfg->ram[i].size);
+ }
+
_FDT(fdt_begin_node(fdt, "memory"));
_FDT(fdt_property_string(fdt, "device_type", "memory"));
- _FDT(fdt_property(fdt, "reg", mem_reg_prop, sizeof(mem_reg_prop)));
+ _FDT(fdt_property(fdt, "reg", mem_reg_prop,
+ 2 * sizeof(fdt64_t) * cfg->nr_ram));
_FDT(fdt_end_node(fdt));
/* CPU and peripherals (interrupt controller, timers, etc) */
diff --git a/arm/include/arm-common/kvm-arch.h b/arm/include/arm-common/kvm-arch.h
index b9d486d..884dda8 100644
--- a/arm/include/arm-common/kvm-arch.h
+++ b/arm/include/arm-common/kvm-arch.h
@@ -12,9 +12,6 @@
#define ARM_AXI_AREA _AC(0x0000000040000000, UL)
#define ARM_MEMORY_AREA _AC(0x0000000080000000, UL)
-#define ARM_LOMAP_MAX_MEMORY ((1ULL << 32) - ARM_MEMORY_AREA)
-#define ARM_HIMAP_MAX_MEMORY ((1ULL << 40) - ARM_MEMORY_AREA)
-
#define ARM_GIC_DIST_BASE (ARM_AXI_AREA - ARM_GIC_DIST_SIZE)
#define ARM_GIC_CPUI_BASE (ARM_GIC_DIST_BASE - ARM_GIC_CPUI_SIZE)
#define ARM_GIC_SIZE (ARM_GIC_DIST_SIZE + ARM_GIC_CPUI_SIZE)
@@ -34,6 +31,8 @@
#define KVM_IOEVENTFD_HAS_PIO 0
+#define ARM_MAX_PHYS_ADDR(cfg) (1UL << ARM_MAX_PHYS_SHIFT(cfg))
+
/*
* On a GICv3 there must be one redistributor per vCPU.
* The value here is the size for one, we multiply this@runtime with
@@ -56,18 +55,27 @@ static inline bool arm_addr_in_ioport_region(u64 phys_addr)
return phys_addr >= KVM_IOPORT_AREA && phys_addr < limit;
}
+#define MAX_RAM_BANKS 8
+
+#define ARCH_SUPPORT_CFG_RAM_BASE 1
+
+struct kvm_arch_ram_region
+{
+ void *start;
+ u64 size;
+};
+
struct kvm_arch {
/*
* We may have to align the guest memory for virtio, so keep the
* original pointers here for munmap.
*/
- void *ram_alloc_start;
- u64 ram_alloc_size;
+ struct kvm_arch_ram_region ram_alloc[MAX_RAM_BANKS];
/*
* Guest addresses for memory layout.
*/
- u64 memory_guest_start;
+ unsigned int nr_mem_banks;
u64 kern_guest_start;
u64 initrd_guest_start;
u64 initrd_size;
diff --git a/arm/kvm.c b/arm/kvm.c
index 34abe69..8a7c611 100644
--- a/arm/kvm.c
+++ b/arm/kvm.c
@@ -11,6 +11,8 @@
#include <linux/kvm.h>
#include <linux/sizes.h>
+#include <stdlib.h>
+
struct kvm_ext kvm_req_ext[] = {
{ DEFINE_KVM_EXT(KVM_CAP_IRQCHIP) },
{ DEFINE_KVM_EXT(KVM_CAP_ONE_REG) },
@@ -24,14 +26,15 @@ bool kvm__arch_cpu_supports_vm(void)
return true;
}
-static void kvm__init_ram(struct kvm *kvm)
+static void kvm__init_ram(struct kvm *kvm,
+ const struct kvm_ram_config *ram_cfg,
+ struct kvm_ram_region *ram,
+ struct kvm_arch_ram_region *ram_alloc)
{
int err;
- u64 phys_start;
unsigned long alignment;
/* Convenience aliases */
const char *hugetlbfs_path = kvm->cfg.hugetlbfs_path;
- struct kvm_ram_region *ram = &kvm->ram[0];
/*
* Allocate guest memory. We must align our buffer to 64K to
@@ -45,37 +48,42 @@ static void kvm__init_ram(struct kvm *kvm)
alignment = SZ_32M;
else
alignment = SZ_2M;
- ram->size = kvm->cfg.ram[0].size;
- kvm->arch.ram_alloc_size = ram->size + alignment;
- kvm->arch.ram_alloc_start = mmap_anon_or_hugetlbfs(kvm, hugetlbfs_path,
- kvm->arch.ram_alloc_size);
+ ram->size = ram_cfg->size;
+ ram_alloc->size = ram->size + alignment;
+ ram_alloc->start = mmap_anon_or_hugetlbfs(kvm, hugetlbfs_path,
+ ram_alloc->size);
- if (kvm->arch.ram_alloc_start == MAP_FAILED)
+ if (ram_alloc->start == MAP_FAILED)
die("Failed to map %lld bytes for guest memory (%d)",
- kvm->arch.ram_alloc_size, errno);
-
- ram->start = (void *)ALIGN((unsigned long)kvm->arch.ram_alloc_start,
- SZ_2M);
+ ram_alloc->size, errno);
- madvise(kvm->arch.ram_alloc_start, kvm->arch.ram_alloc_size,
- MADV_MERGEABLE);
+ ram->start = (void *)ALIGN((unsigned long)ram_alloc->start, SZ_2M);
- madvise(kvm->arch.ram_alloc_start, kvm->arch.ram_alloc_size,
- MADV_HUGEPAGE);
+ madvise(ram_alloc->start, ram_alloc->size, MADV_MERGEABLE);
- phys_start = ARM_MEMORY_AREA;
+ madvise(ram_alloc->start, ram_alloc->size, MADV_HUGEPAGE);
- err = kvm__register_mem(kvm, phys_start, ram->size, ram->start);
+ err = kvm__register_mem(kvm, ram_cfg->base, ram_cfg->size,
+ ram->start);
if (err)
die("Failed to register %lld bytes of memory at physical "
- "address 0x%llx [err %d]", ram->size, phys_start, err);
-
- kvm->arch.memory_guest_start = phys_start;
+ "address 0x%llx [err %d]",
+ ram_cfg->size,
+ ram_cfg->base,
+ err);
+
+ pr_info("Registered memory bank 0x%llx-0x%llx\n",
+ ram_cfg->base,
+ ram_cfg->base + ram_cfg->size);
}
void kvm__arch_delete_ram(struct kvm *kvm)
{
- munmap(kvm->arch.ram_alloc_start, kvm->arch.ram_alloc_size);
+ unsigned int i;
+
+ for (i = 0; i < kvm->nr_ram; i++)
+ munmap(kvm->arch.ram_alloc[i].start,
+ kvm->arch.ram_alloc[i].size);
}
void kvm__arch_read_term(struct kvm *kvm)
@@ -88,27 +96,86 @@ void kvm__arch_set_cmdline(char *cmdline, bool video)
{
}
+/* Only sort the bank by base address */
+static int cmp_bank(const void *p1, const void *p2)
+{
+ const struct kvm_ram_config *bank1 = p1;
+ const struct kvm_ram_config *bank2 = p2;
+
+ if (bank1->base < bank2->base)
+ return -1;
+ else if (bank1->base == bank2->base)
+ return 0;
+ else
+ return 1;
+}
+
static void kvm__arch_sanitize_cfg(struct kvm_config *cfg)
{
+ unsigned int i;
/* Convenience aliases */
struct kvm_ram_config *bank0 = &cfg->ram[0];
- if (bank0->size > ARM_MAX_MEMORY(cfg)) {
- bank0->size = ARM_MAX_MEMORY(cfg);
- pr_warning("sanitize: Capping memory to %lluMB",
- bank0->size >> 20);
+ /*
+ * The user may not have set an address for the first bank. (To keep the
+ * command line backward compatible).
+ */
+ if (bank0->base == INVALID_RAM_ADDR) {
+ /*
+ * Impose the user to set address for the first bank when
+ * multiple banks are specified.
+ */
+ if (cfg->nr_ram > 1)
+ die("sanitize: Base address should be specified for all the banks\n");
+ bank0->base = ARM_MEMORY_AREA;
+ /*
+ * Keep compatibility with old KVM command line behavior where
+ * the memory is capped.
+ */
+ if ((bank0->base + bank0->size) > ARM_MAX_PHYS_ADDR(cfg)) {
+ bank0->size = ARM_MAX_PHYS_ADDR(cfg) - bank0->base;
+ pr_warning("sanitize: Capping memory to %lluMB",
+ bank0->size >> 20);
+ }
}
+
+ /* Sort banks by address to make easier later on. */
+ qsort(cfg->ram, cfg->nr_ram, sizeof(*cfg->ram), cmp_bank);
+
+ /* Check banks are not overlapping */
+ for (i = 1; i < cfg->nr_ram; i++) {
+ const struct kvm_ram_config *bank1 = &cfg->ram[i - 1];
+ const struct kvm_ram_config *bank2 = &cfg->ram[i];
+ unsigned long long end1 = bank1->base + bank1->size - 1;
+ unsigned long long end2 = bank2->base + bank2->size - 1;
+
+ if (!((end1 < bank2->base) || (bank1->base > end2)))
+ die("Memory bank 0x%llx-0x%llx overlapping with 0x%llx-0x%llx\n",
+ bank1->base, end1, bank2->base, end2);
+ }
+
+ /* Check the memory is below the IPA size supported */
+ i = cfg->nr_ram - 1;
+ if ((cfg->ram[i].base + cfg->ram[i].size) > ARM_MAX_PHYS_ADDR(cfg))
+ die("Memory bank outside of the maximum IPA\n");
}
void kvm__arch_init(struct kvm *kvm)
{
+ unsigned int i;
+ /* Convenience aliases */
+ struct kvm_config *cfg = &kvm->cfg;
+
kvm__arch_sanitize_cfg(&kvm->cfg);
/* Create the virtual GIC. */
if (gic__create(kvm, kvm->cfg.arch.irqchip))
die("Failed to create virtual GIC");
- kvm__init_ram(kvm);
+ for (i = 0; i < cfg->nr_ram; i++)
+ kvm__init_ram(kvm, &cfg->ram[i], &kvm->ram[i],
+ &kvm->arch.ram_alloc[i]);
+ kvm->nr_ram = cfg->nr_ram;
}
#define FDT_ALIGN SZ_2M
@@ -125,6 +192,8 @@ bool kvm__arch_load_kernel_image(struct kvm *kvm, int fd_kernel, int fd_initrd,
/*
* Linux requires the initrd and dtb to be mapped inside lowmem,
* so we can't just place them at the top of memory.
+ *
+ * Let's place it in the first memory bank.
*/
limit = ram0->start + min(ram0->size, (u64)SZ_256M) - 1;
@@ -133,7 +202,7 @@ bool kvm__arch_load_kernel_image(struct kvm *kvm, int fd_kernel, int fd_initrd,
file_size = read_file(fd_kernel, pos, limit - pos);
if (file_size < 0) {
if (errno == ENOMEM)
- die("kernel image too big to contain in guest memory.");
+ die("kernel image too big to contain in the first memory bank of the guest.");
die_perror("kernel read");
}
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox