* [PATCH v6 4/6] clk: meson: make the spinlock naming more specific
From: Jerome Brunet @ 2017-12-11 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211064853.32111-5-yixun.lan@amlogic.com>
On Mon, 2017-12-11 at 14:48 +0800, Yixun Lan wrote:
> .ops = &clk_gate_ops,
> diff --git a/drivers/clk/meson/clkc.h b/drivers/clk/meson/clkc.h
> index 1629da9b4141..87f06a801a4d 100644
> --- a/drivers/clk/meson/clkc.h
> +++ b/drivers/clk/meson/clkc.h
> @@ -134,7 +134,7 @@ struct meson_clk_audio_divider {
> struct clk_gate _name = { \
> .reg = (void __iomem *) _reg, \
> .bit_idx = (_bit), \
> - .lock = &clk_lock, \
> + .lock = &meson_clk_lock, \
Something is not right here, line is over 80 characters
Remember to run checkpatch on your series please.
> .hw.init = &(struct clk_init_data) { \
> .name = #_name, \
> .ops = &clk_gate_ops, \
^ permalink raw reply
* [PATCH v3 3/4] rtc: add mxc driver for i.MX53 SRTC
From: Philippe Ombredanne @ 2017-12-11 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211105657.20251-4-linux-kernel-dev@beckhoff.com>
On Mon, Dec 11, 2017 at 11:56 AM, <linux-kernel-dev@beckhoff.com> wrote:
> From: Patrick Bruenn <p.bruenn@beckhoff.com>
>
> Neither rtc-imxdi, rtc-mxc nor rtc-snvs are compatible with i.MX53.
>
> This is driver enables support for the low power domain SRTC features:
> - 32-bit MSB of non-rollover time counter
> - 32-bit alarm register
>
> Select the new config option RTC_DRV_MXC_V2 to build this driver
>
> Based on:
> http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/drivers/rtc/rtc-mxc_v2.c?h=imx_2.6.35_11.09.01
>
> Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com>
[...]
> v2:
[...]
> - add SPDX-License-Identifier and cleanup copyright notice
Thank you for using the SPDX ids in this patch series.
Acked-by: Philippe Ombredanne <pombredanne@nexb.com>
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [PATCH] soc: qcom: Separate kryo l2 accessors from PMU driver
From: Mark Rutland @ 2017-12-11 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002101d37272$60016a20$20043e60$@codeaurora.org>
On Mon, Dec 11, 2017 at 01:22:45PM +0200, ilialin at codeaurora.org wrote:
> Hello Mark,
>
> Do you mean, I should send them as a single series to both lists?
Yes please, with both myself adn Will Deacon explicitly CC'd.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 03/20] ARM: dts: aspeed-g4: Correct VUART IRQ number
From: Arnd Bergmann @ 2017-12-11 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8XfSxxVFT7y6M17LZhVO0GHuL1L=6KET75Qojg8rpgD9iw@mail.gmail.com>
On Mon, Dec 11, 2017 at 11:44 AM, Joel Stanley <joel@jms.id.au> wrote:
> On Mon, Dec 11, 2017 at 6:28 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Mon, Dec 11, 2017 at 6:06 AM, Joel Stanley <joel@jms.id.au> wrote:
>>> This should have always been 8.
>>>
>>> Signed-off-by: Joel Stanley <joel@jms.id.au>
>>
>> As this is a bugfix, should we backport it to stable kernels? When you
>> fix a bug,
>> I generally recommend including a 'Fixes' tag with the commit ID of the patch
>> that introduced the problem, and either a 'Cc: stable at vger.kernel.org' tag
>> if you want it backported, or an explanation in the changelog why it should
>> not get backported. This really helps Greg and the other stable maintainers
>> trying to make a decision what to backport and what not.
>
> We could do this, and I generally follow the practice of adding Fixes
> tags. I hadn't because without an upstream clock driver, the Aspeed
> port is not usable by anyone without making modifications. We're
> really depending on getting that code merged.
>
> I will send it as a fix to 4.15. Do you mind taking individual patches
> for the arm dt tree, or would you prefer a pull request?
For bugfixes, we don't distinguish between DT and other fixes. If it's
a single patch, a pull request works just as well as a emailed patch,
your choice.
Arnd
^ permalink raw reply
* [PATCH] crypto: arm/aes-neonbs Use PTR_ERR_OR_ZERO()
From: Herbert Xu @ 2017-12-11 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1511823966-5815-1-git-send-email-gomonovych@gmail.com>
On Tue, Nov 28, 2017 at 12:06:06AM +0100, Vasyl Gomonovych wrote:
> Fix ptr_ret.cocci warnings:
> arch/arm/crypto/aes-neonbs-glue.c:184:1-3: WARNING: PTR_ERR_OR_ZERO can be used
> arch/arm/crypto/aes-neonbs-glue.c:261:1-3: WARNING: PTR_ERR_OR_ZERO can be used
>
> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
>
> Generated by: scripts/coccinelle/api/ptr_ret.cocci
>
> Signed-off-by: Vasyl Gomonovych <gomonovych@gmail.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] crypto: stm32: fix module device table name
From: Herbert Xu @ 2017-12-11 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171130110433.15811-1-clabbe.montjoie@gmail.com>
On Thu, Nov 30, 2017 at 12:04:33PM +0100, Corentin Labbe wrote:
> This patch fix the following build failure:
> CC [M] drivers/crypto/stm32/stm32-cryp.o
> In file included from drivers/crypto/stm32/stm32-cryp.c:11:0:
> drivers/crypto/stm32/stm32-cryp.c:1049:25: error: 'sti_dt_ids' undeclared here (not in a function)
> MODULE_DEVICE_TABLE(of, sti_dt_ids);
>
> Let's replace sti_dt_ids with stm32_dt_ids which is just declared
> before.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2 22/36] KVM: arm64: Prepare to handle traps on deferred VM sysregs
From: Marc Zyngier @ 2017-12-11 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211112436.GH910@cbox>
On 11/12/17 11:24, Christoffer Dall wrote:
> On Mon, Dec 11, 2017 at 11:10:36AM +0000, Marc Zyngier wrote:
>> On 07/12/17 17:06, Christoffer Dall wrote:
>>> When we defer the save/restore of system registers to vcpu_load and
>>> vcpu_put, we need to take care of the emulation code that handles traps
>>> to these registers, since simply reading the memory array will return
>>> stale data.
>>>
>>> Therefore, introduce two functions to directly read/write the registers
>>> from the physical CPU when we're on a VHE system that has loaded the
>>> system registers onto the physical CPU.
>>>
>>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>>> ---
>>>
>>> Notes:
>>> Changes since v1:
>>> - Removed spurious white space
>>>
>>> arch/arm64/include/asm/kvm_host.h | 4 +++
>>> arch/arm64/kvm/sys_regs.c | 53 +++++++++++++++++++++++++++++++++++++--
>>> 2 files changed, 55 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>>> index de0d55b30b61..f6afe685a280 100644
>>> --- a/arch/arm64/include/asm/kvm_host.h
>>> +++ b/arch/arm64/include/asm/kvm_host.h
>>> @@ -279,6 +279,10 @@ struct kvm_vcpu_arch {
>>>
>>> /* Detect first run of a vcpu */
>>> bool has_run_once;
>>> +
>>> + /* True when deferrable sysregs are loaded on the physical CPU,
>>> + * see kvm_vcpu_load_sysregs and kvm_vcpu_put_sysregs. */
>>> + bool sysregs_loaded_on_cpu;
>>> };
>>>
>>> #define vcpu_gp_regs(v) (&(v)->arch.ctxt.gp_regs)
>>> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
>>> index 62c12ab9e6c4..80adbec933de 100644
>>> --- a/arch/arm64/kvm/sys_regs.c
>>> +++ b/arch/arm64/kvm/sys_regs.c
>>> @@ -35,6 +35,7 @@
>>> #include <asm/kvm_coproc.h>
>>> #include <asm/kvm_emulate.h>
>>> #include <asm/kvm_host.h>
>>> +#include <asm/kvm_hyp.h>
>>> #include <asm/kvm_mmu.h>
>>> #include <asm/perf_event.h>
>>> #include <asm/sysreg.h>
>>> @@ -111,6 +112,54 @@ static bool access_dcsw(struct kvm_vcpu *vcpu,
>>> return true;
>>> }
>>>
>>> +static u64 read_deferrable_vm_reg(struct kvm_vcpu *vcpu, int reg)
>>> +{
>>> + if (vcpu->arch.sysregs_loaded_on_cpu) {
>>> + switch (reg) {
>>> + case SCTLR_EL1: return read_sysreg_el1(sctlr);
>>> + case TTBR0_EL1: return read_sysreg_el1(ttbr0);
>>> + case TTBR1_EL1: return read_sysreg_el1(ttbr1);
>>> + case TCR_EL1: return read_sysreg_el1(tcr);
>>> + case ESR_EL1: return read_sysreg_el1(esr);
>>> + case FAR_EL1: return read_sysreg_el1(far);
>>> + case AFSR0_EL1: return read_sysreg_el1(afsr0);
>>> + case AFSR1_EL1: return read_sysreg_el1(afsr1);
>>> + case MAIR_EL1: return read_sysreg_el1(mair);
>>> + case AMAIR_EL1: return read_sysreg_el1(amair);
>>> + case CONTEXTIDR_EL1: return read_sysreg_el1(contextidr);
>>> + case DACR32_EL2: return read_sysreg(dacr32_el2);
>>> + case IFSR32_EL2: return read_sysreg(ifsr32_el2);
>>> + default: BUG();
>>> + }
>>> + }
>>> +
>>> + return vcpu_sys_reg(vcpu, reg);
>>> +}
>>> +
>>> +static void write_deferrable_vm_reg(struct kvm_vcpu *vcpu, int reg, u64 val)
>>> +{
>>> + if (vcpu->arch.sysregs_loaded_on_cpu) {
>>> + switch (reg) {
>>> + case SCTLR_EL1: write_sysreg_el1(val, sctlr); return;
>>> + case TTBR0_EL1: write_sysreg_el1(val, ttbr0); return;
>>> + case TTBR1_EL1: write_sysreg_el1(val, ttbr1); return;
>>> + case TCR_EL1: write_sysreg_el1(val, tcr); return;
>>> + case ESR_EL1: write_sysreg_el1(val, esr); return;
>>> + case FAR_EL1: write_sysreg_el1(val, far); return;
>>> + case AFSR0_EL1: write_sysreg_el1(val, afsr0); return;
>>> + case AFSR1_EL1: write_sysreg_el1(val, afsr1); return;
>>> + case MAIR_EL1: write_sysreg_el1(val, mair); return;
>>> + case AMAIR_EL1: write_sysreg_el1(val, amair); return;
>>> + case CONTEXTIDR_EL1: write_sysreg_el1(val, contextidr); return;
>>> + case DACR32_EL2: write_sysreg(val, dacr32_el2); return;
>>> + case IFSR32_EL2: write_sysreg(val, ifsr32_el2); return;
>>> + default: BUG();
>>> + }
>>> + }
>>> +
>>> + vcpu_sys_reg(vcpu, reg) = val;
>>> +}
>>> +
>>> /*
>>> * Generic accessor for VM registers. Only called as long as HCR_TVM
>>> * is set. If the guest enables the MMU, we stop trapping the VM
>>> @@ -133,14 +182,14 @@ static bool access_vm_reg(struct kvm_vcpu *vcpu,
>>> if (!p->is_aarch32 || !p->is_32bit) {
>>> val = p->regval;
>>> } else {
>>> - val = vcpu_sys_reg(vcpu, reg);
>>> + val = read_deferrable_vm_reg(vcpu, reg);
>>> if (r->reg % 2)
>>> val = (p->regval << 32) | (u64)lower_32_bits(val);
>>> else
>>> val = ((u64)upper_32_bits(val) << 32) |
>>> (u64)lower_32_bits(p->regval);
>>> }
>>> - vcpu_sys_reg(vcpu, reg) = val;
>>> + write_deferrable_vm_reg(vcpu, reg, val);
>>>
>>> kvm_toggle_cache(vcpu, was_enabled);
>>> return true;
>>>
>>
>> I'm slightly uneasy with this. It means that the rest of the KVM code
>> has to know whether a given register is deferrable or not (or face the
>> wrath of the BUG). I'd be more inclined to hide the "loaded on cpu"
>> magic in the vcpu_sys_reg() accessors.
>>
>> Thoughts?
>>
>
> Yes, this is the main reservation I also have with the series.
>
> I did start out with a giant "rewrite everything to vcpu_get_sys_reg and
> vcpu_get_sys_reg" which hides this logic, and we may want to go back to
> that.
>
> That does mean that we need a giant switch statement which knows how to
> read any deferrable EL1 (and EL0) system register from hardware, and
> still BUG/WARN if someone adds a system register but forgets to add that
> handler and test on VHE. Unless there's some fantastic auto-gen
> mechanism that can take a hash define and figure out which sysreg
> instruction to use - I couldn't think of that.
>
> I'm happy to go back to that approach, but I didn't find it that much
> nicer either.
>
> How about I send you the small handful of patches that implement the
> alternative approach and you have a look at that?
Sure, feel free to post them. I wonder if we can take a similar approach
to the hack I used for the CP15 stuff on 32bit, where read/write_sysreg
are automagically turned into the right type of accessor...
I'll have a try.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] crypto: stm32: fix modular build
From: Arnd Bergmann @ 2017-12-11 11:47 UTC (permalink / raw)
To: linux-arm-kernel
Building the stm32 crypto suport as a loadable module causes a build
failure from a simple typo:
drivers/crypto/stm32/stm32-cryp.c:1035:25: error: 'sti_dt_ids' undeclared here (not in a function); did you mean 'stm32_dt_ids'?
This renames the reference to point to the correct symbol.
Fixes: 9e054ec21ef8 ("crypto: stm32 - Support for STM32 CRYP crypto module")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/crypto/stm32/stm32-cryp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/stm32/stm32-cryp.c b/drivers/crypto/stm32/stm32-cryp.c
index 459755940632..cf1dddbeaa2c 100644
--- a/drivers/crypto/stm32/stm32-cryp.c
+++ b/drivers/crypto/stm32/stm32-cryp.c
@@ -1032,7 +1032,7 @@ static const struct of_device_id stm32_dt_ids[] = {
{ .compatible = "st,stm32f756-cryp", },
{},
};
-MODULE_DEVICE_TABLE(of, sti_dt_ids);
+MODULE_DEVICE_TABLE(of, stm32_dt_ids);
static int stm32_cryp_probe(struct platform_device *pdev)
{
--
2.9.0
^ permalink raw reply related
* [PATCH] nvmem: meson-mx-efuse: fix reading from an offset other than 0
From: Srinivas Kandagatla @ 2017-12-11 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171112183412.12806-1-martin.blumenstingl@googlemail.com>
Hi Martin,
On 12/11/17 18:34, Martin Blumenstingl wrote:
> meson_mx_efuse_read calculates the address internal to the eFuse based
> on the offset and the word size. This works fine with any given offset.
> However, the offset is also included when writing to the output buffer.
> This means that reading 4 bytes at offset 500 tries to write beyond the
> array allocated by the nvmem core as it wants to write the 4 bytes to
> "buffer address + offset (500)".
> This issue did not show up in the previous tests since no driver uses
> any value from the eFuse yet and reading the eFuse via sysfs simply
> reads the whole eFuse, starting at offset 0.
>
> Fix this by only including the offset in the internal address
> calculation.
>
> Fixes: 8caef1fa9176 ("nvmem: add a driver for the Amlogic Meson6/Meson8/Meson8b SoCs")
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
Thanks for your patience,
I will send this to Greg along with other fixes some time this week!
thanks,
srini
> drivers/nvmem/meson-mx-efuse.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/nvmem/meson-mx-efuse.c b/drivers/nvmem/meson-mx-efuse.c
> index a346b4923550..41d3a3c1104e 100644
> --- a/drivers/nvmem/meson-mx-efuse.c
> +++ b/drivers/nvmem/meson-mx-efuse.c
> @@ -156,8 +156,8 @@ static int meson_mx_efuse_read(void *context, unsigned int offset,
> MESON_MX_EFUSE_CNTL1_AUTO_RD_ENABLE,
> MESON_MX_EFUSE_CNTL1_AUTO_RD_ENABLE);
>
> - for (i = offset; i < offset + bytes; i += efuse->config.word_size) {
> - addr = i / efuse->config.word_size;
> + for (i = 0; i < bytes; i += efuse->config.word_size) {
> + addr = (offset + i) / efuse->config.word_size;
>
> err = meson_mx_efuse_read_addr(efuse, addr, &tmp);
> if (err)
>
^ permalink raw reply
* [PATCH v3 01/16] KVM: Take vcpu->mutex outside vcpu_load
From: Cornelia Huck @ 2017-12-11 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-2-cdall@kernel.org>
On Mon, 4 Dec 2017 21:35:23 +0100
Christoffer Dall <cdall@kernel.org> wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> As we're about to call vcpu_load() from architecture-specific
> implementations of the KVM vcpu ioctls, but yet we access data
> structures protected by the vcpu->mutex in the generic code, factor
> this logic out from vcpu_load().
>
> x86 is the only architecture which calls vcpu_load() outside of the main
> vcpu ioctl function, and these calls will no longer take the vcpu mutex
> following this patch. However, with the exception of
> kvm_arch_vcpu_postcreate (see below), the callers are either in the
> creation or destruction path of the VCPU, which means there cannot be
> any concurrent access to the data structure, because the file descriptor
> is not yet accessible, or is already gone.
>
> kvm_arch_vcpu_postcreate makes the newly created vcpu potentially
> accessible by other in-kernel threads through the kvm->vcpus array, and
> we therefore take the vcpu mutex in this case directly.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/x86/kvm/vmx.c | 4 +---
> arch/x86/kvm/x86.c | 20 +++++++-------------
> include/linux/kvm_host.h | 2 +-
> virt/kvm/kvm_main.c | 17 ++++++-----------
> 4 files changed, 15 insertions(+), 28 deletions(-)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* [PATCH v2] ARM: dts: ls1021a: add support for Moxa UC-8410A open platform
From: SZ Lin @ 2017-12-11 11:51 UTC (permalink / raw)
To: linux-arm-kernel
Add support for Moxa UC-8410A open platform
The UC-8410A computing platform is designed
for embedded communication-centric industrial applications
The features of UC-8410A are:
* QSPI flash
* SD slot
* 3x LAN
* 8x RS-232/422/485 ports, software-selectable
* Mini PCIe form factor with PCIe/USB signal
* 2x USB host
* TPM
* Watchdog
* RTC
* User LEDs
* Beeper
* Push button
Signed-off-by: Jimmy Chen <jimmy.chen@moxa.com>
Signed-off-by: Harry YJ Jhou <harryyj.jhou@moxa.com>
Signed-off-by: SZ Lin <sz.lin@moxa.com>
--
Changes from v1:
- Add newline between nodes
- Add push button node
- Insert newline between property list and child node
- Include file of "include/dt-bindings/gpio/gpio.h"
- Include file of "include/dt-bindings/input/input.h"
- Use polartiy defines for gpios to make it more readable
- Put 'status' at the end of property list
- Change GPIO pin number in cel_pwr and cel_reset
- Sort the labeled node alphabetically
- Drop container node of regulator and put fixed regulator directly
under root
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 241 ++++++++++++++++++++++++++++
2 files changed, 242 insertions(+)
create mode 100644 arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d0381e9caf21..62ce9b27ad30 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -520,6 +520,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
imx7s-colibri-eval-v3.dtb \
imx7s-warp.dtb
dtb-$(CONFIG_SOC_LS1021A) += \
+ ls1021a-moxa-uc-8410a.dtb \
ls1021a-qds.dtb \
ls1021a-twr.dtb
dtb-$(CONFIG_SOC_VF610) += \
diff --git a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
new file mode 100644
index 000000000000..bc73b5187990
--- /dev/null
+++ b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
@@ -0,0 +1,241 @@
+/*
+ * Copyright (C) 2017 Moxa Inc. - https://www.moxa.com/
+ *
+ * Author: Harry YJ Jhou (???) <harryyj.jhou@moxa.com>
+ * Jimmy Chen (???) <jimmy.chen@moxa.com>
+ * SZ Lin (???) <sz.lin@moxa.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "ls1021a.dtsi"
+
+/ {
+ model = "Moxa UC-8410A";
+
+ aliases {
+ enet0_rgmii_phy = &rgmii_phy0;
+ enet1_rgmii_phy = &rgmii_phy1;
+ enet2_rgmii_phy = &rgmii_phy2;
+ };
+
+ sys_mclk: clock-mclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24576000>;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ cel_pwr {
+ label = "UC8410A:CEL-PWR";
+ gpios = <&gpio3 27 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ cel_reset {
+ label = "UC8410A:CEL-RESET";
+ gpios = <&gpio3 28 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ str_led {
+ label = "UC8410A:RED:PROG";
+ gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc0";
+ };
+
+ sw_ready {
+ label = "UC8410A:GREEN:SWRDY";
+ gpios = <&gpio0 18 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ beeper {
+ label = "UC8410A:BEEP";
+ gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ prog_led0 {
+ label = "UC8410A:GREEN:PROG2";
+ gpios = <&gpio3 14 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ prog_led1 {
+ label = "UC8410A:GREEN:PROG1";
+ gpios = <&gpio3 15 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ prog_led2 {
+ label = "UC8410A:GREEN:PROG0";
+ gpios = <&gpio3 16 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ wifi_signal0 {
+ label = "UC8410A:GREEN:CEL2";
+ gpios = <&gpio3 17 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ wifi_signal1 {
+ label = "UC8410A:GREEN:CEL1";
+ gpios = <&gpio3 18 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ wifi_signal2 {
+ label = "UC8410A:GREEN:CEL0";
+ gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ cpu_diag_red {
+ label = "UC8410A:RED:DIA";
+ gpios = <&gpio3 20 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ cpu_diag_green {
+ label = "UC8410A:GREEN:DIA";
+ gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ cpu_diag_yellow {
+ label = "UC8410A:YELLOW:DIA";
+ gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pushbtn-key {
+ label = "push button key";
+ gpios = <&gpio1 21 GPIO_ACTIVE_LOW>;
+ linux,code = <BTN_MISC>;
+ default-state = "on";
+ };
+ };
+};
+
+&enet0 {
+ phy-handle = <&rgmii_phy0>;
+ phy-connection-type = "rgmii-id";
+ status = "okay";
+};
+
+&enet1 {
+ phy-handle = <&rgmii_phy1>;
+ phy-connection-type = "rgmii-id";
+ status = "okay";
+};
+
+&enet2 {
+ phy-handle = <&rgmii_phy2>;
+ phy-connection-type = "rgmii-id";
+ status = "okay";
+};
+
+&i2c0 {
+ clock-frequency = <100000>;
+ status = "okay";
+
+ rtc {
+ compatible = "dallas,ds1374";
+ reg = <0x68>;
+ };
+
+ tpm {
+ compatible = "infineon,slb9635tt";
+ reg = <0x20>;
+ };
+};
+
+&lpuart0 {
+ status = "okay";
+};
+
+&mdio0 {
+ rgmii_phy0: ethernet-phy at 0 {
+ compatible = "marvell,88e1118";
+ reg = <0x0>;
+ marvell,reg-init =
+ <3 0x11 0 0x4415>, /* Reg 3,17 */
+ <3 0x10 0 0x77>; /* Reg 3,16 */
+ };
+
+ rgmii_phy1: ethernet-phy at 1 {
+ compatible = "marvell,88e1118";
+ reg = <0x1>;
+ marvell,reg-init =
+ <3 0x11 0 0x4415>, /* Reg 3,17 */
+ <3 0x10 0 0x77>; /* Reg 3,16 */
+ };
+
+ rgmii_phy2: ethernet-phy at 2 {
+ compatible = "marvell,88e1118";
+ reg = <0x2>;
+ marvell,reg-init =
+ <3 0x11 0 0x4415>, /* Reg 3,17 */
+ <3 0x10 0 0x77>; /* Reg 3,16 */
+ };
+};
+
+&qspi {
+ bus-num = <0>;
+ fsl,spi-num-chipselects = <2>;
+ fsl,spi-flash-chipselects = <0>;
+ fsl,qspi-has-second-chip;
+ status = "okay";
+
+ flash: flash at 0 {
+ compatible = "spansion,s25fl064l", "spansion,s25fl164k";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+
+ partitions at 0 {
+ label = "U-Boot";
+ reg = <0x0 0x180000>;
+ };
+
+ partitions at 1 {
+ label = "U-Boot Env";
+ reg = <0x180000 0x680000>;
+ };
+ };
+};
+
+&sata {
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
--
2.15.1
^ permalink raw reply related
* [PATCH v3 02/16] KVM: Prepare for moving vcpu_load/vcpu_put into arch specific code
From: Cornelia Huck @ 2017-12-11 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-3-cdall@kernel.org>
On Mon, 4 Dec 2017 21:35:24 +0100
Christoffer Dall <cdall@kernel.org> wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> In preparation for moving calls to vcpu_load() and vcpu_put() into the
> architecture specific implementations of the KVM vcpu ioctls, move the
> calls in the main kvm_vcpu_ioctl() dispatcher function to each case
> of the ioctl select statement. This allows us to move the vcpu_load()
> and vcpu_put() calls into architecture specific implementations of vcpu
> ioctls, one by one.
>
> Reviewed-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> virt/kvm/kvm_main.c | 26 ++++++++++++++++++++++++--
> 1 file changed, 24 insertions(+), 2 deletions(-)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* [RESEND PATCH] arm64: v8.4: Support for new floating point multiplication variant
From: Dave P Martin @ 2017-12-11 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512833322-35503-1-git-send-email-gengdongjiu@huawei.com>
On Sat, Dec 09, 2017 at 03:28:42PM +0000, Dongjiu Geng wrote:
> ARM v8.4 extensions include support for new floating point
> multiplication variant instructions to the AArch64 SIMD
Do we have any human-readable description of what the new instructions
do?
Since the v8.4 spec itself only describes these as "New Floating
Point Multiplication Variant", I wonder what "FHM" actually stands
for.
Maybe something like "widening half-precision floating-point multiply
accumulate" is acceptable wording consistent with the existing
architecture, but I just made that up, so it's not official ;)
> instructions set. Let the userspace know about it via a
> HWCAP bit and MRS emulation.
>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
> ---
> My platform supports this feature, so I need to add it.
> ---
> Documentation/arm64/cpu-feature-registers.txt | 4 +++-
> arch/arm64/include/asm/sysreg.h | 1 +
> arch/arm64/include/uapi/asm/hwcap.h | 1 +
> arch/arm64/kernel/cpufeature.c | 2 ++
> arch/arm64/kernel/cpuinfo.c | 1 +
> 5 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/arm64/cpu-feature-registers.txt b/Documentation/arm64/cpu-feature-registers.txt
> index bd9b3fa..a70090b 100644
> --- a/Documentation/arm64/cpu-feature-registers.txt
> +++ b/Documentation/arm64/cpu-feature-registers.txt
> @@ -110,7 +110,9 @@ infrastructure:
> x--------------------------------------------------x
> | Name | bits | visible |
> |--------------------------------------------------|
> - | RES0 | [63-48] | n |
> + | RES0 | [63-52] | n |
> + |--------------------------------------------------|
> + | FHM | [51-48] | y |
You also need to update Documentation/arm64/elf_hwcaps.txt.
Otherwise, looks OK.
Cheers
---Dave
> |--------------------------------------------------|
> | DP | [47-44] | y |
> |--------------------------------------------------|
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index 08cc885..1818077 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -419,6 +419,7 @@
> #define SCTLR_EL1_CP15BEN (1 << 5)
>
> /* id_aa64isar0 */
> +#define ID_AA64ISAR0_FHM_SHIFT 48
> #define ID_AA64ISAR0_DP_SHIFT 44
> #define ID_AA64ISAR0_SM4_SHIFT 40
> #define ID_AA64ISAR0_SM3_SHIFT 36
> diff --git a/arch/arm64/include/uapi/asm/hwcap.h b/arch/arm64/include/uapi/asm/hwcap.h
> index cda76fa..f018c3d 100644
> --- a/arch/arm64/include/uapi/asm/hwcap.h
> +++ b/arch/arm64/include/uapi/asm/hwcap.h
> @@ -43,5 +43,6 @@
> #define HWCAP_ASIMDDP (1 << 20)
> #define HWCAP_SHA512 (1 << 21)
> #define HWCAP_SVE (1 << 22)
> +#define HWCAP_ASIMDFHM (1 << 23)
>
> #endif /* _UAPI__ASM_HWCAP_H */
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index c5ba009..bc7e707 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -123,6 +123,7 @@ static int __init register_cpu_hwcaps_dumper(void)
> * sync with the documentation of the CPU feature register ABI.
> */
> static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_FHM_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_DP_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SM4_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SM3_SHIFT, 4, 0),
> @@ -991,6 +992,7 @@ static bool has_no_fpsimd(const struct arm64_cpu_capabilities *entry, int __unus
> HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM3_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SM3),
> HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_SM4_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_SM4),
> HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_DP_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_ASIMDDP),
> + HWCAP_CAP(SYS_ID_AA64ISAR0_EL1, ID_AA64ISAR0_FHM_SHIFT, FTR_UNSIGNED, 1, CAP_HWCAP, HWCAP_ASIMDFHM),
> HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_FP),
> HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_FP_SHIFT, FTR_SIGNED, 1, CAP_HWCAP, HWCAP_FPHP),
> HWCAP_CAP(SYS_ID_AA64PFR0_EL1, ID_AA64PFR0_ASIMD_SHIFT, FTR_SIGNED, 0, CAP_HWCAP, HWCAP_ASIMD),
> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> index 1e25545..7f94623 100644
> --- a/arch/arm64/kernel/cpuinfo.c
> +++ b/arch/arm64/kernel/cpuinfo.c
> @@ -76,6 +76,7 @@
> "asimddp",
> "sha512",
> "sve",
> + "asimdfhm",
> NULL
> };
>
> --
> 1.9.1
>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* [PATCH 04/12] arm64: Initialise high_memory global variable earlier
From: Catalin Marinas @ 2017-12-11 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204141313.31604-5-steve.capper@arm.com>
On Mon, Dec 04, 2017 at 02:13:05PM +0000, Steve Capper wrote:
> The high_memory global variable is used by
> cma_declare_contiguous(.) before it is defined.
>
> We don't notice this as we compute __pa(high_memory - 1), and it looks
> like we're processing a VA from the direct linear map.
>
> This problem becomes apparent when we flip the kernel virtual address
> space and the linear map is moved to the bottom of the kernel VA space.
>
> This patch moves the initialisation of high_memory before it used.
>
> Signed-off-by: Steve Capper <steve.capper@arm.com>
It looks like we've had this bug since 3.18 (f7426b983a6a, "mm: cma:
adjust address limit to avoid hitting low/high memory boundary"). It may
be worth adding a cc stable on this patch.
--
Catalin
^ permalink raw reply
* [PATCH v3 03/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_run
From: Cornelia Huck @ 2017-12-11 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-4-cdall@kernel.org>
On Mon, 4 Dec 2017 21:35:25 +0100
Christoffer Dall <cdall@kernel.org> wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_run().
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/mips/kvm/mips.c | 3 +++
> arch/powerpc/kvm/powerpc.c | 6 +++++-
> arch/s390/kvm/kvm-s390.c | 10 ++++++++--
> arch/x86/kvm/x86.c | 3 +++
> virt/kvm/arm/arm.c | 15 +++++++++++----
> virt/kvm/kvm_main.c | 2 --
> 6 files changed, 30 insertions(+), 9 deletions(-)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* [PATCH net-next v5 2/2] net: ethernet: socionext: add AVE ethernet driver
From: Kunihiko Hayashi @ 2017-12-11 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOFm3uELNTgenR91-QGL1QQ08zA0N0rQbH4hzCzFKtRw6TckLw@mail.gmail.com>
On Mon, 11 Dec 2017 10:19:15 +0100 Phlippe Ombredanne <pombredanne@nexb.com> wrote:
> Dear Kunihiko-san,
>
> On Mon, Dec 11, 2017 at 8:57 AM, Kunihiko Hayashi
> <hayashi.kunihiko@socionext.com> wrote:
> > The UniPhier platform from Socionext provides the AVE ethernet
> > controller that includes MAC and MDIO bus supporting RGMII/RMII
> > modes. The controller is named AVE.
> >
> > Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> > Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> [...]
> > --- /dev/null
> > +++ b/drivers/net/ethernet/socionext/Makefile
> > @@ -0,0 +1,5 @@
> > +# SPDX-License-Identifier: GPL-2.0
>
> You are correctly using SPDX ids here....
>
> > +obj-$(CONFIG_SNI_AVE) += sni_ave.o
> > diff --git a/drivers/net/ethernet/socionext/sni_ave.c b/drivers/net/ethernet/socionext/sni_ave.c
> > new file mode 100644
> > index 0000000..7b293c2
> > --- /dev/null
> > +++ b/drivers/net/ethernet/socionext/sni_ave.c
> > @@ -0,0 +1,1744 @@
> > +/**
> > + * sni_ave.c - Socionext UniPhier AVE ethernet driver
> > + *
> > + * Copyright 2014 Panasonic Corporation
> > + * Copyright 2015-2017 Socionext Inc.
> > + *
> > + * This program is free software: you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 of
> > + * the License as published by the Free Software Foundation.
> > + *
> > + * This program 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.
> > + */
>
> ... then I guess you could also use them here, replacing at least 7
> lines of boilerplate by a single id line?
>
> > +// SDPX-License-Identifier: GPL-2.0
Thank you for your kindly comment.
It seems there are few ethernet drivers applying SPDX-License-Identifier
to C source, then it has been difficult for me to decide whether to replace
boilerplate.
If it's no problem to apply SPDX to sources of ethernet drivers,
I'll replace it with the single line.
> And if you go C++ style all the way, this could be even more compact:
>
> > +// SDPX-License-Identifier: GPL-2.0
> > +// sni_ave.c - Socionext UniPhier AVE ethernet driver
> > +// Copyright 2014 Panasonic Corporation
> > +// Copyright 2015-2017 Socionext Inc.
It's much simpler.
If it's reasonable to apply this style here, I can replace it, too.
Thank you,
---
Best Regards,
Kunihiko Hayashi
^ permalink raw reply
* [PATCH v3 04/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_get_regs
From: Cornelia Huck @ 2017-12-11 12:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-5-cdall@kernel.org>
On Mon, 4 Dec 2017 21:35:26 +0100
Christoffer Dall <cdall@kernel.org> wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_get_regs().
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/mips/kvm/mips.c | 3 +++
> arch/powerpc/kvm/book3s.c | 3 +++
> arch/powerpc/kvm/booke.c | 3 +++
> arch/s390/kvm/kvm-s390.c | 2 ++
> arch/x86/kvm/x86.c | 3 +++
> virt/kvm/kvm_main.c | 2 --
> 6 files changed, 14 insertions(+), 2 deletions(-)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* [PATCH net-next] net: thunderx: Add support for xdp redirect
From: Jesper Dangaard Brouer @ 2017-12-11 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171124120328.7600-1-aleksey.makarov@cavium.com>
On Fri, 24 Nov 2017 15:03:26 +0300
Aleksey Makarov <aleksey.makarov@cavium.com> wrote:
> From: Sunil Goutham <sgoutham@cavium.com>
>
> This patch adds support for XDP_REDIRECT. Flush is not
> yet supported.
>
> Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
> Signed-off-by: cjacob <cjacob@caviumnetworks.com>
> Signed-off-by: Aleksey Makarov <aleksey.makarov@cavium.com>
> ---
> drivers/net/ethernet/cavium/thunder/nicvf_main.c | 110 ++++++++++++++++-----
> drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 11 ++-
> drivers/net/ethernet/cavium/thunder/nicvf_queues.h | 4 +
> 3 files changed, 94 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> index a063c36c4c58..b82e28262c57 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> @@ -65,6 +65,11 @@ module_param(cpi_alg, int, S_IRUGO);
> MODULE_PARM_DESC(cpi_alg,
> "PFC algorithm (0=none, 1=VLAN, 2=VLAN16, 3=IP Diffserv)");
>
> +struct nicvf_xdp_tx {
> + u64 dma_addr;
> + u8 qidx;
> +};
> +
[...]
> static inline bool nicvf_xdp_rx(struct nicvf *nic, struct bpf_prog *prog,
> struct cqe_rx_t *cqe_rx, struct snd_queue *sq,
> struct sk_buff **skb)
> {
> struct xdp_buff xdp;
> struct page *page;
> + struct nicvf_xdp_tx *xdp_tx = NULL;
> u32 action;
> - u16 len, offset = 0;
> + u16 len, err, offset = 0;
> u64 dma_addr, cpu_addr;
> void *orig_data;
>
> @@ -521,7 +541,7 @@ static inline bool nicvf_xdp_rx(struct nicvf *nic, struct bpf_prog *prog,
> cpu_addr = (u64)phys_to_virt(cpu_addr);
> page = virt_to_page((void *)cpu_addr);
>
> - xdp.data_hard_start = page_address(page);
> + xdp.data_hard_start = page_address(page) + RCV_BUF_HEADROOM;
> xdp.data = (void *)cpu_addr;
> xdp_set_data_meta_invalid(&xdp);
> xdp.data_end = xdp.data + len;
[...]
> @@ -564,6 +573,20 @@ static inline bool nicvf_xdp_rx(struct nicvf *nic, struct bpf_prog *prog,
> case XDP_TX:
> nicvf_xdp_sq_append_pkt(nic, sq, (u64)xdp.data, dma_addr, len);
> return true;
> + case XDP_REDIRECT:
> + /* Save DMA address for use while transmitting */
> + xdp_tx = (struct nicvf_xdp_tx *)page_address(page);
> + xdp_tx->dma_addr = dma_addr;
> + xdp_tx->qidx = nicvf_netdev_qidx(nic, cqe_rx->rq_idx);
Hey, this sucks... You cannot just invent your own in-driver usage of
the XDP packet headroom. That is specific to your driver only. In
effect you can only XDP_REDIRECT from your driver out your own driver.
The XDP_TX action is for driver/port local redirect. The XDP_REDIRECT
action is between drivers.
> +
> + err = xdp_do_redirect(nic->pnicvf->netdev, &xdp, prog);
> + if (!err)
> + return true;
> +
> + /* Free the page on error */
> + nicvf_unmap_page(nic, page, dma_addr);
> + put_page(page);
> + break;
> default:
> bpf_warn_invalid_xdp_action(action);
> /* fall through */
[...]
> @@ -1764,6 +1776,50 @@ static int nicvf_xdp(struct net_device *netdev, struct netdev_bpf *xdp)
> }
> }
>
> +static int nicvf_xdp_xmit(struct net_device *netdev, struct xdp_buff *xdp)
This is a generic ndo_xdp_xmit that other drivers can call.
> +{
> + struct nicvf *nic = netdev_priv(netdev);
> + struct nicvf *snic = nic;
> + struct nicvf_xdp_tx *xdp_tx;
> + struct snd_queue *sq;
> + struct page *page;
> + int err, qidx;
> +
> + if (!netif_running(netdev) || !nic->xdp_prog)
> + return -EINVAL;
> +
> + page = virt_to_page(xdp->data);
> + xdp_tx = (struct nicvf_xdp_tx *)page_address(page);
> + qidx = xdp_tx->qidx;
What is another driver XDP_REDIRECT a frame to your driver?
> +
> + if (xdp_tx->qidx >= nic->xdp_tx_queues)
> + return -EINVAL;
> +
> + /* Get secondary Qset's info */
> + if (xdp_tx->qidx >= MAX_SND_QUEUES_PER_QS) {
> + qidx = xdp_tx->qidx / MAX_SND_QUEUES_PER_QS;
> + snic = (struct nicvf *)nic->snicvf[qidx - 1];
> + if (!snic)
> + return -EINVAL;
> + qidx = xdp_tx->qidx % MAX_SND_QUEUES_PER_QS;
> + }
> +
> + sq = &snic->qs->sq[qidx];
> + err = nicvf_xdp_sq_append_pkt(snic, sq, (u64)xdp->data,
> + xdp_tx->dma_addr,
> + xdp->data_end - xdp->data);
> + if (err)
> + return -ENOMEM;
> +
> + nicvf_xdp_sq_doorbell(snic, sq, qidx);
> + return 0;
> +}
> +
> +static void nicvf_xdp_flush(struct net_device *dev)
> +{
> + return;
> +}
> +
> static const struct net_device_ops nicvf_netdev_ops = {
> .ndo_open = nicvf_open,
> .ndo_stop = nicvf_stop,
> @@ -1775,6 +1831,8 @@ static const struct net_device_ops nicvf_netdev_ops = {
> .ndo_fix_features = nicvf_fix_features,
> .ndo_set_features = nicvf_set_features,
> .ndo_bpf = nicvf_xdp,
> + .ndo_xdp_xmit = nicvf_xdp_xmit,
> + .ndo_xdp_flush = nicvf_xdp_flush,
> };
[...]
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
> index 67d1a3230773..178ab6e8e3c5 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
> @@ -11,6 +11,7 @@
>
> #include <linux/netdevice.h>
> #include <linux/iommu.h>
> +#include <linux/bpf.h>
> #include "q_struct.h"
>
> #define MAX_QUEUE_SET 128
> @@ -92,6 +93,9 @@
> #define RCV_FRAG_LEN (SKB_DATA_ALIGN(DMA_BUFFER_LEN + NET_SKB_PAD) + \
> SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
>
> +#define RCV_BUF_HEADROOM 128 /* To store dma address for XDP redirect */
> +#define XDP_HEADROOM (XDP_PACKET_HEADROOM + RCV_BUF_HEADROOM)
> +
> #define MAX_CQES_FOR_TX ((SND_QUEUE_LEN / MIN_SQ_DESC_PER_PKT_XMIT) * \
> MAX_CQE_PER_PKT_XMIT)
>
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH v3 05/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_set_regs
From: Cornelia Huck @ 2017-12-11 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-6-cdall@kernel.org>
On Mon, 4 Dec 2017 21:35:27 +0100
Christoffer Dall <cdall@kernel.org> wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_set_regs().
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/mips/kvm/mips.c | 3 +++
> arch/powerpc/kvm/book3s.c | 3 +++
> arch/powerpc/kvm/booke.c | 3 +++
> arch/s390/kvm/kvm-s390.c | 2 ++
> arch/x86/kvm/x86.c | 3 +++
> virt/kvm/kvm_main.c | 2 --
> 6 files changed, 14 insertions(+), 2 deletions(-)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* [PATCH v3 06/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_get_sregs
From: Cornelia Huck @ 2017-12-11 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-7-cdall@kernel.org>
On Mon, 4 Dec 2017 21:35:28 +0100
Christoffer Dall <cdall@kernel.org> wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_get_sregs().
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/powerpc/kvm/book3s.c | 8 +++++++-
> arch/powerpc/kvm/booke.c | 9 ++++++++-
> arch/s390/kvm/kvm-s390.c | 4 ++++
> arch/x86/kvm/x86.c | 3 +++
> virt/kvm/kvm_main.c | 2 --
> 5 files changed, 22 insertions(+), 4 deletions(-)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* [PATCH v3 07/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_set_sregs
From: Cornelia Huck @ 2017-12-11 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-8-cdall@kernel.org>
On Mon, 4 Dec 2017 21:35:29 +0100
Christoffer Dall <cdall@kernel.org> wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_set_sregs().
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/powerpc/kvm/book3s.c | 8 +++++++-
> arch/powerpc/kvm/booke.c | 15 +++++++++++----
> arch/s390/kvm/kvm-s390.c | 4 ++++
> arch/x86/kvm/x86.c | 13 ++++++++++---
> virt/kvm/kvm_main.c | 2 --
> 5 files changed, 32 insertions(+), 10 deletions(-)
With David's suggestions included:
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* [PATCH v3 08/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_get_mpstate
From: Cornelia Huck @ 2017-12-11 12:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-9-cdall@kernel.org>
On Mon, 4 Dec 2017 21:35:30 +0100
Christoffer Dall <cdall@kernel.org> wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_get_mpstate().
>
> Reviewed-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/s390/kvm/kvm-s390.c | 11 +++++++++--
> arch/x86/kvm/x86.c | 3 +++
> virt/kvm/arm/arm.c | 3 +++
> virt/kvm/kvm_main.c | 2 --
> 4 files changed, 15 insertions(+), 4 deletions(-)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* [PATCH v3 09/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_set_mpstate
From: Cornelia Huck @ 2017-12-11 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-10-cdall@kernel.org>
On Mon, 4 Dec 2017 21:35:31 +0100
Christoffer Dall <cdall@kernel.org> wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_set_mpstate().
>
> Reviewed-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/s390/kvm/kvm-s390.c | 3 +++
> arch/x86/kvm/x86.c | 14 +++++++++++---
> virt/kvm/arm/arm.c | 9 +++++++--
> virt/kvm/kvm_main.c | 2 --
> 4 files changed, 21 insertions(+), 7 deletions(-)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* [PATCH v3 10/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_translate
From: Cornelia Huck @ 2017-12-11 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-11-cdall@kernel.org>
On Mon, 4 Dec 2017 21:35:32 +0100
Christoffer Dall <cdall@kernel.org> wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_translate().
>
> Reviewed-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/powerpc/kvm/booke.c | 2 ++
> arch/x86/kvm/x86.c | 3 +++
> virt/kvm/kvm_main.c | 2 --
> 3 files changed, 5 insertions(+), 2 deletions(-)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ permalink raw reply
* [PATCH v3 11/16] KVM: Move vcpu_load to arch-specific kvm_arch_vcpu_ioctl_set_guest_debug
From: Cornelia Huck @ 2017-12-11 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204203538.8370-12-cdall@kernel.org>
On Mon, 4 Dec 2017 21:35:33 +0100
Christoffer Dall <cdall@kernel.org> wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Move vcpu_load() and vcpu_put() into the architecture specific
> implementations of kvm_arch_vcpu_ioctl_set_guest_debug().
>
> Reviewed-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/arm64/kvm/guest.c | 15 ++++++++++++---
> arch/powerpc/kvm/book3s.c | 2 ++
> arch/powerpc/kvm/booke.c | 19 +++++++++++++------
> arch/s390/kvm/kvm-s390.c | 16 ++++++++++++----
> arch/x86/kvm/x86.c | 4 +++-
> virt/kvm/kvm_main.c | 2 --
> 6 files changed, 42 insertions(+), 16 deletions(-)
>
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 1b491b89cd43..7cb0e2677e60 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -2018,12 +2018,15 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
> {
> struct debug_reg *dbg_reg;
> int n, b = 0, w = 0;
> + int ret = 0;
> +
> + vcpu_load(vcpu);
>
> if (!(dbg->control & KVM_GUESTDBG_ENABLE)) {
> vcpu->arch.dbg_reg.dbcr0 = 0;
> vcpu->guest_debug = 0;
> kvm_guest_protect_msr(vcpu, MSR_DE, false);
> - return 0;
> + goto out;
> }
>
> kvm_guest_protect_msr(vcpu, MSR_DE, true);
> @@ -2055,8 +2058,9 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
> #endif
>
> if (!(vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP))
> - return 0;
> + goto out;
>
> + ret = -EINVAL;
> for (n = 0; n < (KVMPPC_BOOKE_IAC_NUM + KVMPPC_BOOKE_DAC_NUM); n++) {
> uint64_t addr = dbg->arch.bp[n].addr;
> uint32_t type = dbg->arch.bp[n].type;
> @@ -2067,21 +2071,24 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
> if (type & ~(KVMPPC_DEBUG_WATCH_READ |
> KVMPPC_DEBUG_WATCH_WRITE |
> KVMPPC_DEBUG_BREAKPOINT))
> - return -EINVAL;
> + goto out;
>
> if (type & KVMPPC_DEBUG_BREAKPOINT) {
> /* Setting H/W breakpoint */
> if (kvmppc_booke_add_breakpoint(dbg_reg, addr, b++))
> - return -EINVAL;
> + goto out;
> } else {
> /* Setting H/W watchpoint */
> if (kvmppc_booke_add_watchpoint(dbg_reg, addr,
> type, w++))
> - return -EINVAL;
> + goto out;
> }
> }
>
> - return 0;
> + ret = 0;
I would probably set the -EINVAL in the individual branches (so it is
clear that something is wrong, and it is not just a benign exit as in
the cases above), but your code is correct as well. Let the powerpc
folks decide.
> +out:
> + vcpu_put(vcpu);
> + return ret;
> }
>
> void kvmppc_booke_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
In any case,
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
^ 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