* [patch v21 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver
From: Andy Shevchenko @ 2018-05-15 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526394095-5069-3-git-send-email-oleksandrs@mellanox.com>
On Tue, May 15, 2018 at 5:21 PM, Oleksandr Shamray
<oleksandrs@mellanox.com> wrote:
> Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller.
>
> Driver implements the following jtag ops:
> - freq_get;
> - freq_set;
> - status_get;
> - idle;
> - xfer;
>
> It has been tested on Mellanox system with BMC equipped with
> Aspeed 2520 SoC for programming CPLD devices.
> +#define ASPEED_JTAG_DATA 0x00
> +#define ASPEED_JTAG_INST 0x04
> +#define ASPEED_JTAG_CTRL 0x08
> +#define ASPEED_JTAG_ISR 0x0C
> +#define ASPEED_JTAG_SW 0x10
> +#define ASPEED_JTAG_TCK 0x14
> +#define ASPEED_JTAG_EC 0x18
> +
> +#define ASPEED_JTAG_DATA_MSB 0x01
> +#define ASPEED_JTAG_DATA_CHUNK_SIZE 0x20
> +#define ASPEED_JTAG_IOUT_LEN(len) (ASPEED_JTAG_CTL_ENG_EN |\
> + ASPEED_JTAG_CTL_ENG_OUT_EN |\
> + ASPEED_JTAG_CTL_INST_LEN(len))
Better to read
#define MY_COOL_CONST_OR_MACRO(xxx) \
...
> +#define ASPEED_JTAG_DOUT_LEN(len) (ASPEED_JTAG_CTL_ENG_EN |\
> + ASPEED_JTAG_CTL_ENG_OUT_EN |\
> + ASPEED_JTAG_CTL_DATA_LEN(len))
Ditto.
> +static char *end_status_str[] = {"idle", "ir pause", "drpause"};
> +static int aspeed_jtag_freq_set(struct jtag *jtag, u32 freq)
> +{
> + struct aspeed_jtag *aspeed_jtag = jtag_priv(jtag);
> + unsigned long apb_frq;
> + u32 tck_val;
> + u16 div;
> +
> + apb_frq = clk_get_rate(aspeed_jtag->pclk);
> + div = (apb_frq % freq == 0) ? (apb_frq / freq) - 1 : (apb_frq / freq);
Isn't it the same as
div = (apb_frq - 1) / freq;
?
> + tck_val = aspeed_jtag_read(aspeed_jtag, ASPEED_JTAG_TCK);
> + aspeed_jtag_write(aspeed_jtag,
> + (tck_val & ASPEED_JTAG_TCK_DIVISOR_MASK) | div,
> + ASPEED_JTAG_TCK);
> + return 0;
> +}
> +static void aspeed_jtag_sw_delay(struct aspeed_jtag *aspeed_jtag, int cnt)
> +{
> + int i;
> +
> + for (i = 0; i < cnt; i++)
> + aspeed_jtag_read(aspeed_jtag, ASPEED_JTAG_SW);
Isn't it readsl() (or how it's called, I don't remember).
> +}
> +static void aspeed_jtag_wait_instruction_pause(struct aspeed_jtag *aspeed_jtag)
> +{
> + wait_event_interruptible(aspeed_jtag->jtag_wq, aspeed_jtag->flag &
> + ASPEED_JTAG_ISR_INST_PAUSE);
In such cases I prefer to see a new line with a parameter in full.
Check all places.
> + aspeed_jtag->flag &= ~ASPEED_JTAG_ISR_INST_PAUSE;
> +}
> +static void aspeed_jtag_sm_cycle(struct aspeed_jtag *aspeed_jtag, const u8 *tms,
> + int len)
> +{
> + int i;
> +
> + for (i = 0; i < len; i++)
> + aspeed_jtag_tck_cycle(aspeed_jtag, tms[i], 0);
> +}
> +
> +static void aspeed_jtag_run_test_idle_sw(struct aspeed_jtag *aspeed_jtag,
> + struct jtag_run_test_idle *runtest)
> +{
> + static const u8 sm_pause_irpause[] = {1, 1, 1, 1, 0, 1, 0};
> + static const u8 sm_pause_drpause[] = {1, 1, 1, 0, 1, 0};
> + static const u8 sm_idle_irpause[] = {1, 1, 0, 1, 0};
> + static const u8 sm_idle_drpause[] = {1, 0, 1, 0};
> + static const u8 sm_pause_idle[] = {1, 1, 0};
> + int i;
> +
> + /* SW mode from idle/pause-> to pause/idle */
> + if (runtest->reset) {
> + for (i = 0; i < ASPEED_JTAG_RESET_CNTR; i++)
> + aspeed_jtag_tck_cycle(aspeed_jtag, 1, 0);
> + }
I would rather split this big switch to a few helper functions per
each status of surrounding switch.
> +
> + /* Stay on IDLE for at least TCK cycle */
> + for (i = 0; i < runtest->tck; i++)
> + aspeed_jtag_tck_cycle(aspeed_jtag, 0, 0);
> +}
> +/**
> + * aspeed_jtag_run_test_idle:
> + * JTAG reset: generates at least 9 TMS high and 1 TMS low to force
> + * devices into Run-Test/Idle State.
> + */
It's rather broken kernel doc.
> + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_CTL_ENG_EN |
> + ASPEED_JTAG_CTL_ENG_OUT_EN |
> + ASPEED_JTAG_CTL_FORCE_TMS, ASPEED_JTAG_CTRL);
> + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_EC_GO_IDLE,
> + ASPEED_JTAG_EC);
> + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_SW_MODE_EN |
> + ASPEED_JTAG_SW_MODE_TDIO, ASPEED_JTAG_SW);
Here you have permutations of flag some of which are repeatetive in
the code. Perhaps make additional definitions instead.
Check other similar places.
> + char tdo;
Indentation.
> + if (xfer->direction == JTAG_READ_XFER)
> + tdi = UINT_MAX;
> + else
> + tdi = data[index];
> + if (xfer->direction == JTAG_READ_XFER)
> + tdi = UINT_MAX;
> + else
> + tdi = data[index];
Take your time to think how the above duplication can be avoided.
> + }
> + }
> +
> + tdo = aspeed_jtag_tck_cycle(aspeed_jtag, 1, tdi & ASPEED_JTAG_DATA_MSB);
> + data[index] |= tdo << (shift_bits % ASPEED_JTAG_DATA_CHUNK_SIZE);
> +}
> + if (endstate != JTAG_STATE_IDLE) {
Why not to use positive check?
> + int i;
> +
> + for (i = 0; i <= xfer->length / BITS_PER_BYTE; i++) {
> + pos += snprintf(&dbg_str[pos], sizeof(dbg_str) - pos,
> + "0x%02x ", xfer_data[i]);
> + }
Oh, NO! Consider reading printk-formats (for %*ph) and other
documentation about available APIs.
> + if (!(aspeed_jtag->mode & JTAG_XFER_HW_MODE)) {
> + /* SW mode */
This is rather too complex to be in one function.
> + } else {
> + /* hw mode */
> + aspeed_jtag_write(aspeed_jtag, 0, ASPEED_JTAG_SW);
> + aspeed_jtag_xfer_hw(aspeed_jtag, xfer, data);
For symmetry it might be another function.
> + }
> + dev_dbg(aspeed_jtag->dev, "status %x\n", status);
Perhaps someone should become familiar with tracepoints?
> + dev_err(aspeed_jtag->dev, "irq status:%x\n",
> + status);
Huh, really?! SPAM.
(I would drop it completely, though you may use ratelimited variant)
> + ret = IRQ_NONE;
> + }
> + return ret;
> +}
> + clk_prepare_enable(aspeed_jtag->pclk);
This might fail.
> + dev_dbg(&pdev->dev, "IRQ %d.\n", aspeed_jtag->irq);
Noise even for debug.
> + err = jtag_register(jtag);
Perhaps we might have devm_ variant of this. Check how SPI framework
deal with a such.
> +static int aspeed_jtag_remove(struct platform_device *pdev)
> +{
> + struct jtag *jtag;
> +
> + jtag = platform_get_drvdata(pdev);
Usually we put this on one line
> + aspeed_jtag_deinit(pdev, jtag_priv(jtag));
> + jtag_unregister(jtag);
> + jtag_free(jtag);
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v12 4/4] arm64: handle NOTIFY_SEI notification by the APEI driver
From: Dongjiu Geng @ 2018-05-15 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526417887-25843-1-git-send-email-gengdongjiu@huawei.com>
Add a helper to handle the NOTIFY_SEI notification, when kernel
gets the NOTIFY_SEI notification, call this helper and let APEI
driver to handle this notification.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
---
arch/arm64/include/asm/system_misc.h | 1 +
arch/arm64/kernel/traps.c | 4 ++++
arch/arm64/mm/fault.c | 10 ++++++++++
3 files changed, 15 insertions(+)
diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
index 07aa8e3..9ee13ad 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -57,6 +57,7 @@ void hook_debug_fault_code(int nr, int (*fn)(unsigned long, unsigned int,
})
int handle_guest_sea(phys_addr_t addr, unsigned int esr);
+int handle_guest_sei(void);
#endif /* __ASSEMBLY__ */
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index bbb0fde..d888eb2 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -681,6 +681,10 @@ bool arm64_is_fatal_ras_serror(struct pt_regs *regs, unsigned int esr)
{
u32 aet = arm64_ras_serror_get_severity(esr);
+ /* The APEI driver may handle this RAS error. */
+ if (!handle_guest_sei())
+ return false;
+
switch (aet) {
case ESR_ELx_AET_CE: /* corrected error */
case ESR_ELx_AET_UEO: /* restartable, not yet consumed */
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index f76bb2c..8f29bd8 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -683,6 +683,16 @@ int handle_guest_sea(phys_addr_t addr, unsigned int esr)
return ret;
}
+int handle_guest_sei(void)
+{
+ int ret = -ENOENT;
+
+ if (IS_ENABLED(CONFIG_ACPI_APEI_SEI))
+ ret = ghes_notify_sei();
+
+ return ret;
+}
+
asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
--
1.9.1
^ permalink raw reply related
* [PATCH v12 3/4] ACPI / APEI: Add SEI notification type support for ARMv8
From: Dongjiu Geng @ 2018-05-15 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526417887-25843-1-git-send-email-gengdongjiu@huawei.com>
ACPI 6.x adds support for NOTIFY_SEI as a GHES notification
mechanism, so add new GHES notification handling functions.
Expose API ghes_notify_sei() to arch code, arch code will call
this API when it gets this NOTIFY_SEI.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Note:
Firmware will follow the SError mask rule, if the SError is masked,
the firmware will not deliver NOTIFY_SEI notification.
---
drivers/acpi/apei/Kconfig | 15 ++++++++++++++
drivers/acpi/apei/ghes.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++
include/acpi/ghes.h | 1 +
3 files changed, 69 insertions(+)
diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
index 52ae543..ff4afc3 100644
--- a/drivers/acpi/apei/Kconfig
+++ b/drivers/acpi/apei/Kconfig
@@ -55,6 +55,21 @@ config ACPI_APEI_SEA
option allows the OS to look for such hardware error record, and
take appropriate action.
+config ACPI_APEI_SEI
+ bool "APEI SError(System Error) Interrupt logging/recovering support"
+ depends on ARM64 && ACPI_APEI_GHES
+ default y
+ help
+ This option should be enabled if the system supports
+ firmware first handling of SEI (SError interrupt).
+
+ SEI happens with asynchronous external abort for errors on device
+ memory reads on ARMv8 systems. If a system supports firmware first
+ handling of SEI, the platform analyzes and handles hardware error
+ notifications from SEI, and it may then form a hardware error record for
+ the OS to parse and handle. This option allows the OS to look for
+ such hardware error record, and take appropriate action.
+
config ACPI_APEI_MEMORY_FAILURE
bool "APEI memory error recovering support"
depends on ACPI_APEI && MEMORY_FAILURE
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 1efefe9..33f77ae 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -827,6 +827,46 @@ static inline void ghes_sea_add(struct ghes *ghes) { }
static inline void ghes_sea_remove(struct ghes *ghes) { }
#endif /* CONFIG_ACPI_APEI_SEA */
+#ifdef CONFIG_ACPI_APEI_SEI
+static LIST_HEAD(ghes_sei);
+
+/*
+ * Return 0 only if one of the SEI error sources successfully reported an error
+ * record sent from the firmware.
+ */
+int ghes_notify_sei(void)
+{
+ struct ghes *ghes;
+ int ret = -ENOENT;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(ghes, &ghes_sei, list) {
+ if (!ghes_proc(ghes))
+ ret = 0;
+ }
+ rcu_read_unlock();
+ return ret;
+}
+
+static void ghes_sei_add(struct ghes *ghes)
+{
+ mutex_lock(&ghes_list_mutex);
+ list_add_rcu(&ghes->list, &ghes_sei);
+ mutex_unlock(&ghes_list_mutex);
+}
+
+static void ghes_sei_remove(struct ghes *ghes)
+{
+ mutex_lock(&ghes_list_mutex);
+ list_del_rcu(&ghes->list);
+ mutex_unlock(&ghes_list_mutex);
+ synchronize_rcu();
+}
+#else /* CONFIG_ACPI_APEI_SEI */
+static inline void ghes_sei_add(struct ghes *ghes) { }
+static inline void ghes_sei_remove(struct ghes *ghes) { }
+#endif /* CONFIG_ACPI_APEI_SEI */
+
#ifdef CONFIG_HAVE_ACPI_APEI_NMI
/*
* printk is not safe in NMI context. So in NMI handler, we allocate
@@ -1055,6 +1095,13 @@ static int ghes_probe(struct platform_device *ghes_dev)
goto err;
}
break;
+ case ACPI_HEST_NOTIFY_SEI:
+ if (!IS_ENABLED(CONFIG_ACPI_APEI_SEI)) {
+ pr_warn(GHES_PFX "Generic hardware error source: %d notified via SEI is not supported!\n",
+ generic->header.source_id);
+ goto err;
+ }
+ break;
case ACPI_HEST_NOTIFY_NMI:
if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
pr_warn(GHES_PFX "Generic hardware error source: %d notified via NMI interrupt is not supported!\n",
@@ -1126,6 +1173,9 @@ static int ghes_probe(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_SEA:
ghes_sea_add(ghes);
break;
+ case ACPI_HEST_NOTIFY_SEI:
+ ghes_sei_add(ghes);
+ break;
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_add(ghes);
break;
@@ -1179,6 +1229,9 @@ static int ghes_remove(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_SEA:
ghes_sea_remove(ghes);
break;
+ case ACPI_HEST_NOTIFY_SEI:
+ ghes_sei_remove(ghes);
+ break;
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_remove(ghes);
break;
diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
index 8feb0c8..9ba59e2 100644
--- a/include/acpi/ghes.h
+++ b/include/acpi/ghes.h
@@ -120,5 +120,6 @@ static inline void *acpi_hest_get_next(struct acpi_hest_generic_data *gdata)
section = acpi_hest_get_next(section))
int ghes_notify_sea(void);
+int ghes_notify_sei(void);
#endif /* GHES_H */
--
1.9.1
^ permalink raw reply related
* [PATCH v12 2/4] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
From: Dongjiu Geng @ 2018-05-15 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526417887-25843-1-git-send-email-gengdongjiu@huawei.com>
For the migrating VMs, user space may need to know the exception
state. For example, in the machine A, KVM make an SError pending,
when migrate to B, KVM also needs to pend an SError.
This new IOCTL exports user-invisible states related to SError.
Together with appropriate user space changes, user space can get/set
the SError exception state to do migrate/snapshot/suspend.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Change since V11:
Address James's comments, thanks James
1. Align the struct of kvm_vcpu_events to 64 bytes
2. Avoid exposing the stale ESR value in the kvm_arm_vcpu_get_events()
3. Change variables 'injected' name to 'serror_pending' in the kvm_arm_vcpu_set_events()
4. change to sizeof(events) from sizeof(struct kvm_vcpu_events) in kvm_arch_vcpu_ioctl()
Change since V10:
Address James's comments, thanks James
1. Merge the helper function with the user.
2. Move the ISS_MASK into pend_guest_serror() to clear top bits
3. Make kvm_vcpu_events struct align to 4 bytes
4. Add something check in the kvm_arm_vcpu_set_events()
5. Check kvm_arm_vcpu_get/set_events()'s return value.
6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't
contain kernel stack.
---
Documentation/virtual/kvm/api.txt | 31 ++++++++++++++++++++++++++++---
arch/arm/include/asm/kvm_host.h | 6 ++++++
arch/arm/kvm/guest.c | 12 ++++++++++++
arch/arm64/include/asm/kvm_emulate.h | 5 +++++
arch/arm64/include/asm/kvm_host.h | 7 +++++++
arch/arm64/include/uapi/asm/kvm.h | 13 +++++++++++++
arch/arm64/kvm/guest.c | 36 ++++++++++++++++++++++++++++++++++++
arch/arm64/kvm/inject_fault.c | 7 ++++++-
arch/arm64/kvm/reset.c | 1 +
virt/kvm/arm/arm.c | 21 +++++++++++++++++++++
10 files changed, 135 insertions(+), 4 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 66494a5..36a9dc3 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -819,11 +819,13 @@ struct kvm_clock_data {
Capability: KVM_CAP_VCPU_EVENTS
Extended by: KVM_CAP_INTR_SHADOW
-Architectures: x86
+Architectures: x86, arm, arm64
Type: vm ioctl
Parameters: struct kvm_vcpu_event (out)
Returns: 0 on success, -1 on error
+X86:
+
Gets currently pending exceptions, interrupts, and NMIs as well as related
states of the vcpu.
@@ -865,15 +867,32 @@ Only two fields are defined in the flags field:
- KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that
smi contains a valid state.
+ARM, ARM64:
+
+Gets currently pending SError exceptions as well as related states of the vcpu.
+
+struct kvm_vcpu_events {
+ struct {
+ __u8 serror_pending;
+ __u8 serror_has_esr;
+ /* Align it to 8 bytes */
+ __u8 pad[6];
+ __u64 serror_esr;
+ } exception;
+ __u32 reserved[12];
+};
+
4.32 KVM_SET_VCPU_EVENTS
-Capability: KVM_CAP_VCPU_EVENTS
+Capebility: KVM_CAP_VCPU_EVENTS
Extended by: KVM_CAP_INTR_SHADOW
-Architectures: x86
+Architectures: x86, arm, arm64
Type: vm ioctl
Parameters: struct kvm_vcpu_event (in)
Returns: 0 on success, -1 on error
+X86:
+
Set pending exceptions, interrupts, and NMIs as well as related states of the
vcpu.
@@ -894,6 +913,12 @@ shall be written into the VCPU.
KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available.
+ARM, ARM64:
+
+Set pending SError exceptions as well as related states of the vcpu.
+
+See KVM_GET_VCPU_EVENTS for the data structure.
+
4.33 KVM_GET_DEBUGREGS
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index ef54013..d81621e 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -211,6 +211,12 @@ struct kvm_vcpu_stat {
int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
unsigned long kvm_call_hyp(void *hypfn, ...);
void force_vm_exit(const cpumask_t *mask);
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index 1e0784e..39f895d 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -248,6 +248,18 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
}
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ return -EINVAL;
+}
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ return -EINVAL;
+}
+
int __attribute_const__ kvm_target_cpu(void)
{
switch (read_cpuid_part()) {
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 413dc82..3294885 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -71,6 +71,11 @@ static inline void vcpu_set_hcr(struct kvm_vcpu *vcpu, unsigned long hcr)
vcpu->arch.hcr_el2 = hcr;
}
+static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu)
+{
+ return vcpu->arch.vsesr_el2;
+}
+
static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr)
{
vcpu->arch.vsesr_el2 = vsesr;
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index a73f63a..1125540 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -326,6 +326,11 @@ struct kvm_vcpu_stat {
int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
#define KVM_ARCH_WANT_MMU_NOTIFIER
int kvm_unmap_hva(struct kvm *kvm, unsigned long hva);
@@ -354,6 +359,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run *run,
int kvm_perf_init(void);
int kvm_perf_teardown(void);
+void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
+
struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr,
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 9abbf30..d815b67 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -39,6 +39,7 @@
#define __KVM_HAVE_GUEST_DEBUG
#define __KVM_HAVE_IRQ_LINE
#define __KVM_HAVE_READONLY_MEM
+#define __KVM_HAVE_VCPU_EVENTS
#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
@@ -153,6 +154,18 @@ struct kvm_sync_regs {
struct kvm_arch_memory_slot {
};
+/* for KVM_GET/SET_VCPU_EVENTS */
+struct kvm_vcpu_events {
+ struct {
+ __u8 serror_pending;
+ __u8 serror_has_esr;
+ /* Align it to 8 bytes */
+ __u8 pad[6];
+ __u64 serror_esr;
+ } exception;
+ __u32 reserved[12];
+};
+
/* If you need to interpret the index values, here is the key: */
#define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
#define KVM_REG_ARM_COPROC_SHIFT 16
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 5c7f657..f9b7e8f 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -277,6 +277,42 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
}
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ events->exception.serror_pending = (vcpu_get_hcr(vcpu) & HCR_VSE);
+ events->exception.serror_has_esr =
+ cpus_have_const_cap(ARM64_HAS_RAS_EXTN) &&
+ (!!vcpu_get_vsesr(vcpu));
+
+ if (events->exception.serror_pending &&
+ events->exception.serror_has_esr)
+ events->exception.serror_esr = vcpu_get_vsesr(vcpu);
+ else
+ events->exception.serror_esr = 0;
+
+ return 0;
+}
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ bool serror_pending = events->exception.serror_pending;
+ bool has_esr = events->exception.serror_has_esr;
+
+ if (serror_pending && has_esr) {
+ if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN))
+ return -EINVAL;
+
+ kvm_set_sei_esr(vcpu, events->exception.serror_esr);
+
+ } else if (serror_pending) {
+ kvm_inject_vabt(vcpu);
+ }
+
+ return 0;
+}
+
int __attribute_const__ kvm_target_cpu(void)
{
unsigned long implementor = read_cpuid_implementor();
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index 60666a0..aa0358a 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -166,7 +166,7 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu)
static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr)
{
- vcpu_set_vsesr(vcpu, esr);
+ vcpu_set_vsesr(vcpu, esr & ESR_ELx_ISS_MASK);
vcpu_set_hcr(vcpu, vcpu_get_hcr(vcpu) | HCR_VSE);
}
@@ -186,3 +186,8 @@ void kvm_inject_vabt(struct kvm_vcpu *vcpu)
{
pend_guest_serror(vcpu, ESR_ELx_ISV);
}
+
+void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome)
+{
+ pend_guest_serror(vcpu, syndrome);
+}
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 38c8a64..20e919a 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
+ case KVM_CAP_VCPU_EVENTS:
r = 1;
break;
default:
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index 7e3941f..e466f5d 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -1051,6 +1051,27 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
return -EFAULT;
return kvm_arm_vcpu_has_attr(vcpu, &attr);
}
+ case KVM_GET_VCPU_EVENTS: {
+ struct kvm_vcpu_events events;
+
+ memset(&events, 0, sizeof(events));
+ if (kvm_arm_vcpu_get_events(vcpu, &events))
+ return -EINVAL;
+
+ if (copy_to_user(argp, &events, sizeof(events)))
+ return -EFAULT;
+
+ return 0;
+ }
+ case KVM_SET_VCPU_EVENTS: {
+ struct kvm_vcpu_events events;
+
+ if (copy_from_user(&events, argp,
+ sizeof(struct kvm_vcpu_events)))
+ return -EFAULT;
+
+ return kvm_arm_vcpu_set_events(vcpu, &events);
+ }
default:
return -EINVAL;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v12 1/4] arm64: KVM: export the capability to set guest SError syndrome
From: Dongjiu Geng @ 2018-05-15 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526417887-25843-1-git-send-email-gengdongjiu@huawei.com>
For the arm64 RAS Extension, user space can inject a virtual-SError
with specified ESR. So user space needs to know whether KVM support
to inject such SError, this interface adds this query for this capability.
KVM will check whether system support RAS Extension, if supported, KVM
returns true to user space, otherwise returns false.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Reviewed-by: James Morse <james.morse@arm.com>
Change from V11:
1. Change the commit message
2. Update the Documentation/virtual/kvm/api.tx
---
Documentation/virtual/kvm/api.txt | 11 +++++++++++
arch/arm64/kvm/reset.c | 3 +++
include/uapi/linux/kvm.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index fc3ae95..66494a5 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4415,3 +4415,14 @@ Parameters: none
This capability indicates if the flic device will be able to get/set the
AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows
to discover this without having to create a flic device.
+
+8.14 KVM_CAP_ARM_SET_SERROR_ESR
+
+Architectures: arm, arm64
+
+This capability indicates that userspace can specify the syndrome value reported
+to the guest OS when guest takes a virtual SError interrupt exception.
+If KVM has this capability, userspace can only specify the ISS field for the ESR
+syndrome, it can not specify the EC field which is not under control by KVM.
+If this virtual SError is taken to EL1 using AArch64, this value will be reported
+in ISS filed of ESR_EL1.
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 3256b92..38c8a64 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_ARM_PMU_V3:
r = kvm_arm_support_pmu_v3();
break;
+ case KVM_CAP_ARM_INJECT_SERROR_ESR:
+ r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN);
+ break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
r = 1;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 8fb90a0..3587b33 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -934,6 +934,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_S390_AIS_MIGRATION 150
#define KVM_CAP_PPC_GET_CPU_CHAR 151
#define KVM_CAP_S390_BPB 152
+#define KVM_CAP_ARM_INJECT_SERROR_ESR 153
#ifdef KVM_CAP_IRQ_ROUTING
--
1.9.1
^ permalink raw reply related
* [PATCH v12 0/4] set VSESR_EL2 by user space and support NOTIFY_SEI notification
From: Dongjiu Geng @ 2018-05-15 20:58 UTC (permalink / raw)
To: linux-arm-kernel
1. Detect whether KVM can set set guest SError syndrome
2. Support to Set VSESR_EL2 and inject SError by user space.
3. Support live migration to keep SError pending state and VSESR_EL2 value.
4. ACPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so support this
notification in software, KVM or kernel ARCH code call handle_guest_sei() to let ACP driver
to handle this notification.
Change since V11:
Address James's comments, thanks James
1. Align the struct of kvm_vcpu_events to 64 bytes
2. Avoid exposing the stale ESR value in the kvm_arm_vcpu_get_events()
3. Change variables 'injected' name to 'serror_pending' in the kvm_arm_vcpu_set_events()
4. Change to sizeof(events) from sizeof(struct kvm_vcpu_events) in kvm_arch_vcpu_ioctl()
5. Update the patches commit message and document description
Change since V10:
Address James's comments, thanks James
1. Merge the helper function with the user.
2. Move the ISS_MASK into pend_guest_serror() to clear top bits
3. Make kvm_vcpu_events struct align to 4 bytes
4. Add something check in the kvm_arm_vcpu_set_events()
5. Check kvm_arm_vcpu_get/set_events()'s return value.
6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't
contain kernel stack.
Dongjiu Geng (4):
arm64: KVM: export the capability to set guest SError syndrome
arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
ACPI / APEI: Add SEI notification type support for ARMv8
arm64: handle NOTIFY_SEI notification by the APEI driver
Documentation/virtual/kvm/api.txt | 42 ++++++++++++++++++++++++++--
arch/arm/include/asm/kvm_host.h | 6 ++++
arch/arm/kvm/guest.c | 12 ++++++++
arch/arm64/include/asm/kvm_emulate.h | 5 ++++
arch/arm64/include/asm/kvm_host.h | 7 +++++
arch/arm64/include/asm/system_misc.h | 1 +
arch/arm64/include/uapi/asm/kvm.h | 13 +++++++++
arch/arm64/kernel/traps.c | 4 +++
arch/arm64/kvm/guest.c | 36 ++++++++++++++++++++++++
arch/arm64/kvm/inject_fault.c | 7 ++++-
arch/arm64/kvm/reset.c | 4 +++
arch/arm64/mm/fault.c | 10 +++++++
drivers/acpi/apei/Kconfig | 15 ++++++++++
drivers/acpi/apei/ghes.c | 53 ++++++++++++++++++++++++++++++++++++
include/acpi/ghes.h | 1 +
include/uapi/linux/kvm.h | 1 +
virt/kvm/arm/arm.c | 21 ++++++++++++++
17 files changed, 234 insertions(+), 4 deletions(-)
--
1.9.1
^ permalink raw reply
* [GIT PULL 4/4] Rockchip arm64 defconfig updates for 4.18 round 1
From: Olof Johansson @ 2018-05-15 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2676342.8y6AX4oR9f@phil>
On Tue, May 15, 2018 at 12:40:05PM +0200, Heiko Stuebner wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.18-rockchip-defconfig64-1
>
> for you to fetch changes up to 214f2c319a140f8a0121f362ad8e73ea1576d5ad:
>
> arm64: defconfig: enable rockchip efuse (2018-05-09 16:33:09 +0200)
>
> ----------------------------------------------------------------
> Enablement of Rockchip-specific efuse, io-domain and typec drivers
> as well as general cros-ec, hid, touchscreen bluetooth and wifi-drivers
> on 64bit arm platforms.
>
> ----------------------------------------------------------------
> Enric Balletbo i Serra (3):
> arm64: defconfig: Enable typec-phy and extcon-usbc-cros-ec for rk3399
> arm64: defconfig: Enable Rockchip io-domain driver
> arm64: defconfig: Enable ChromeOS EC drivers for supported Chromebooks.
>
> Ezequiel Garcia (4):
> arm64: defconfig: Enable HID over I2C drivers
> arm64: defconfig: Enable Atmel Maxtouch driver
> arm64: defconfig: Enable Marvell WiFi-Ex PCIe driver
> arm64: defconfig: Enable bluetooth USB support
>
> Heiko Stuebner (1):
> arm64: defconfig: enable rockchip efuse
Merged. Not sure if it's useful to split defconfig updates quite this granular,
might make sense to just do slightly more consolidated patches.
Anyway, no harm, just a bit verbose.
-Olof
^ permalink raw reply
* [GIT PULL 3/4] Rockchip dts64 updates for 4.18 round 1
From: Olof Johansson @ 2018-05-15 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20114925.REm1YfjZS7@phil>
On Tue, May 15, 2018 at 12:39:26PM +0200, Heiko Stuebner wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.18-rockchip-dts64-1
>
> for you to fetch changes up to 17bd0737948aa841b76278a601217b914aa5f18e:
>
> arm64: dts: rockchip: enable hdmi on rk3399-puma-haikou (2018-05-03 14:38:20 +0200)
>
> ----------------------------------------------------------------
> All iommus got their clocks added and rk3399 got support for its
> usb3-phy otg-port and better ajustment for the cpll child clocks.
> On the board side, all rk3399 got their typec phys enabled - which
> is needed for better usb support, the sapphire board got some more
> properties moved to the excavator baseboard where they really belong,
> kevin got a fix to use a real devicetree compatible and puma-haikou
> got its hdmi port enabled.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 2/4] Rockchip dts32 updates for 4.18 round 1
From: Olof Johansson @ 2018-05-15 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2461510.NP0ZiRnFEz@phil>
On Tue, May 15, 2018 at 12:38:49PM +0200, Heiko Stuebner wrote:
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.18-rockchip-dts32-1
>
> for you to fetch changes up to 08624814cbec12b1ce877bf80f6990ad2b9cdcd7:
>
> ARM: dts: rockchip: default serial for rk3288 Tinker Board (2018-04-20 14:55:07 +0200)
>
> ----------------------------------------------------------------
> Fixed pin numbers for uart4 on rk3288, iommu clocks and small changes
> over multiple boards like default serial setting for rk3288-tinker,
> output selection for the dp83867 on the phycore-som and the newly
> added pwm-backlight delay properties for veyron boards.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL 1/4] Rockchip driver updates for 4.18 round 1
From: Olof Johansson @ 2018-05-15 20:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2000491.bLgWuj0xar@phil>
On Tue, May 15, 2018 at 12:38:09PM +0200, Heiko Stuebner wrote:
> Hi Arnd, Kevin Olof,
>
> please find below and in the replies the main pull requests for Rockchip
> stuff for 4.18. Depending on timing there may or may not be a second
> round but so far I don't have anything big on the radar.
>
> The signed tags should explain the individual contents, so please pull.
>
>
> Thanks
> Heiko
>
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v4.18-rockchip-drivers-1
>
> for you to fetch changes up to 9e59c5f66c624b43c766a9fe3b2430e0e976bf0e:
>
> soc: rockchip: power-domain: Fix wrong value when power up pd with writemask (2018-05-14 11:53:26 +0200)
>
> ----------------------------------------------------------------
> Fix for an issue introduced in 2016 where some powerdomains could only
> be turned off but not on again.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] DaVinci fixes for v4.17 (part 2)
From: Olof Johansson @ 2018-05-15 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fcf8613b-31df-733b-3443-c1a6176cbdd1@ti.com>
On Tue, May 15, 2018 at 02:52:14PM +0530, Sekhar Nori wrote:
> The following changes since commit 9411ac07cd764be34bbd7ff09125a6b7b9175d4c:
>
> ARM: davinci: fix GPIO lookup for I2C (2018-05-02 14:55:06 +0530)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v4.17-part-2
>
> for you to fetch changes up to bb7298a7e87cf3430eb62be8746e5d7a07ca9d7c:
>
> ARM: davinci: board-dm646x-evm: set VPIF capture card name (2018-05-15 14:31:12 +0530)
>
> ----------------------------------------------------------------
> Second set of fixes for TI DaVinci.
>
> They are needed for DM6467 EVM to work. The first patch fixes an
> issue with timer interrupt and the second two are needed for video
> driver to probe successfully.
Merged, thanks.
Was DM6467 ever working, so is this a regression?
-Olof
^ permalink raw reply
* [GIT PULL] Reset controller changes for v4.18
From: Olof Johansson @ 2018-05-15 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526374427.2303.3.camel@pengutronix.de>
On Tue, May 15, 2018 at 10:53:47AM +0200, Philipp Zabel wrote:
> Dear arm-soc maintainers,
>
> The following changes since commit e6914365fd280fce303a89b8a8d4529af5a2e0f9:
>
> reset: uniphier: fix USB clock line for LD20 (2018-04-27 11:51:12 +0200)
>
> are available in the Git repository at:
>
> git://git.pengutronix.de/pza/linux.git tags/reset-for-4.18
>
> for you to fetch changes up to d7bab65b1f57cdf2d81fc469cea6b2160a50e917:
>
> reset: uniphier: add LD11/LD20 stream demux system reset control (2018-04-27 11:59:05 +0200)
>
> ----------------------------------------------------------------
> Reset controller changes for v4.18
>
> This adds PCIe, SATA, and HSC reset control support on various Uniphier
> SoCs. PCIe reset control is added for Pro5, LD20, and PXs3 SoCs, SATA
> reset control support is added on Pro4 and PXs3 SoCs. The previously
> added PXs2 SATA reset control identifier is changed to the same value
> for consistency. HSC (MPEG2 transport stream I/O and demux system) reset
> controls are added for LD11 and LD20 SoCs.
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] firmware: scmi: updates for v4.18
From: Olof Johansson @ 2018-05-15 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514162607.GC8409@e107155-lin>
On Mon, May 14, 2018 at 05:26:07PM +0100, Sudeep Holla wrote:
> Hi ARM-SoC team,
>
> Please pull !
>
> Regards,
> Sudeep
>
> --
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scmi-updates-4.18
>
> for you to fetch changes up to 632de8f542bcd44c756637da0e7d824e7129e496:
>
> firmware: arm_scmi: simplify exit path by returning on error (2018-05-10 10:52:00 +0100)
>
> ----------------------------------------------------------------
> SCMI cleanups for v4.18
>
> This contains all of the trivial review comments that were not
> addressed as the series was already queued up for v4.17 and were not
> critical to go as fixes.
>
> They generally just improve code readability, fix kernel-docs, remove
> unused/unnecessary code, follow standard function naming and simplifies
> certain exit paths.
Nice! Merged into next/drivers now.
-Olof
^ permalink raw reply
* [GIT PULL] arm64: dts: juno: updates for v4.18
From: Olof Johansson @ 2018-05-15 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514162317.GB8409@e107155-lin>
On Mon, May 14, 2018 at 05:23:17PM +0100, Sudeep Holla wrote:
> Hi ARM-SoC team,
>
> Please pull !
>
> Note that the tag is based on v4.17-rc3 instead of -rc1 as a fix went in
> -rc3 and conflicts with changes here. The conflicts themselves are
> trivial and hence I can based the change on -rc1 if required.
>
> Regards,
> Sudeep
>
> --
>
> The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64:
>
> Linux v4.17-rc3 (2018-04-29 14:17:42 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/juno-updates-4.18
>
> for you to fetch changes up to 349b0f95e1ea718d912ca6875a40813e52a4ba39:
>
> arm64: dts: juno/rtsm: re-structure motherboard includes (2018-05-10 11:01:56 +0100)
>
> ----------------------------------------------------------------
> ARMv8 Juno/Vexpress updates/cleanups for v4.18
>
> 1. Add the missing connections to the STM output port as all endpoint
> connections must be bidirectional.
>
> 2. Replace all the custom OF graph endpoint node names with the standard
> 'endpoint'
>
> 3. Cleanup to replace all underscores('_') with hyphens('-') in the
> device node names
>
> 4. Syntactic restructuring of motherboard include file so that it can be
> included at the top of any other DTS file as it should be rather than
> existing include in the middle of the file at a specific location
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] ARM: dts: vexpress: updates for v4.18
From: Olof Johansson @ 2018-05-15 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514162144.GA8409@e107155-lin>
On Mon, May 14, 2018 at 05:21:44PM +0100, Sudeep Holla wrote:
> Hi ARM-SoC team,
>
> Please pull !
>
> Note that the commit restructuring motherboard dtsi touches the file
> in ARM64 DT but that's because of the way the file gets included and
> it's not something newly introduced here.
>
> Regards,
> Sudeep
>
> --
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/vexpress-updates-4.18
>
> for you to fetch changes up to b67b00eeddac0fea494d6339618ffd3da071c2e4:
>
> ARM: dts: vexpress: replace '_' with '-' in node names (2018-05-11 14:12:32 +0100)
>
> ----------------------------------------------------------------
> ARMv7 Vexpress updates/cleanups for v4.18
>
> 1. Syntactic restructuring of motherboard include file so that it can be
> included at the top of any other DTS file as it should be rather than
> existing include in the middle of the file at a specific location
>
> 2. Use of standard GPIO controller bindings for few sysreg components
> like LED, MMC Write Protect/Card Detect and Flash Write Protect
> to fix some of the new DTC warnings
>
> 3. Cleanup to replace all underscores('_') with hyphens('-') in the
> device node names
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] STi DT update for v4.18 round 1
From: Olof Johansson @ 2018-05-15 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <11f8376c-860d-26cf-92f6-38737e513656@st.com>
On Mon, May 14, 2018 at 03:56:08PM +0000, Patrice CHOTARD wrote:
> Hi Arnd, Kevin, Olof
>
> PLease consider this first round of STi dts update for v4.18
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git
> tags/sti-dt-for-v4.18-round1
>
> for you to fetch changes up to c5bf208a0dc4aee18e03c6ed97eada70ffa9a4d8:
>
> ARM: dts: stihxxx-b2120: Fix complain about IRQ_TYPE_NONE usage
> (2018-05-14 17:40:26 +0200)
>
> ----------------------------------------------------------------
> STi DT update for 4.18:
> - Fix complain about IRQ_TYPE_NONE_usage
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: mediatek: soc driver updates for v4.18
From: Olof Johansson @ 2018-05-15 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bd033549-4998-e376-eb92-16111ec71a07@gmail.com>
On Mon, May 14, 2018 at 01:32:49PM +0200, Matthias Brugger wrote:
> Hi Arnd and Olof,
>
> Below the commits for mediatek soc drivers.
> Please beware that we need the regmap-ktime-fix [1] from Mark Browns static tag.
> I merged that into my branch, but I wanted to let you know, so that you don't
> hit any breakage when pulling in my branch.
Great, and thanks for mentioning it.
>
> Regards,
> Matthias
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
> tags/regmap-ktime-fix
>
> ---
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
> tags/v4.17-next-soc
>
> for you to fetch changes up to 0afd32c6bb59e41b6692dec4473efaffffcad67b:
>
> Merge commit 'f15cd6d99198e9c15229aefec639a34a6e8174c6' into
> v.4.17-next/soc-test (2018-05-14 12:22:03 +0200)
Merged into next/drivers. Thanks!
-Olof
^ permalink raw reply
* [RFC PATCH 07/10] clk: rockchip: set clk-ddr to GET_RATE_NOCACHE.
From: Stephen Boyd @ 2018-05-15 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514211610.26618-8-enric.balletbo@collabora.com>
Quoting Enric Balletbo i Serra (2018-05-14 14:16:07)
> From: Derek Basehore <dbasehore@chromium.org>
>
> This adds the flag to the clk-ddr in rockchip to not use the cached
> rate for get_rate. This is to handle timeout error conditions in SMC
> for the set rate function.
We need some more information here. Why does timeout error condition in
set_rate() matter for get_rate()?
^ permalink raw reply
* [GIT PULL] ARM: mediatek: dts64 updates for v4.18
From: Olof Johansson @ 2018-05-15 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e36e9a49-4913-25a8-16a9-31c1fbbfddc9@gmail.com>
On Mon, May 14, 2018 at 01:28:16PM +0200, Matthias Brugger wrote:
> Hi you two,
>
> Please take into account the following commit to 64-bit DTS.
>
> Thanks a lot,
> Matthias
>
> ---
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
> tags/v4.17-next-dts64
>
> for you to fetch changes up to f1e0d0d8cf454202d21140aace184cc5512a9fdd:
>
> arm64: dts: mt7622: add audio related device nodes (2018-05-11 18:42:20 +0200)
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: mediatek: updates of dts32 for v4.18
From: Olof Johansson @ 2018-05-15 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7205c939-b8f6-7da7-bca3-0b7951ebbdf4@gmail.com>
On Mon, May 14, 2018 at 01:26:17PM +0200, Matthias Brugger wrote:
> Hi Arnd,
> Hi Olof,
>
> please have a look on the following updates for 32-bit DTS files.
>
> Thanks,
> Matthias
>
> ---
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
> tags/v4.17-next-dts32
>
> for you to fetch changes up to dd0dcf003dd86caba7726cc1e2ef268f1cf11aae:
>
> arm: dts: mt7623: add MT7623N reference board with eMMC (2018-05-11 17:52:28
> +0200)
Merged, thanks!
-Olof
^ permalink raw reply
* [GIT PULL] defconfig updates for v4.18
From: Olof Johansson @ 2018-05-15 20:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <268190dc-bca5-d86a-c56c-75013dc20d38@gmail.com>
On Mon, May 14, 2018 at 01:24:03PM +0200, Matthias Brugger wrote:
> Hi Olof and Arnd,
>
> Please merge the following patch for defconfig.
>
> Thanks,
> Matthias
>
> ---
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/
> tags/v4.17-next-defconfig
>
> for you to fetch changes up to 1e31927aa64545ee97a2a41db9984c9931afc50a:
>
> arm64: defconfig: Enable CONFIG_PINCTRL_MT7622 by default (2018-04-27 11:48:37
> +0200)
>
> ----------------------------------------------------------------
> enable mt7622 pinctrl to fix boot issue
Merged, thanks!
-Olof
^ permalink raw reply
* [PATCH] clk: stm32mp1: Fix a memory leak in 'clk_stm32_register_gate_ops()'
From: Stephen Boyd @ 2018-05-15 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513111704.31842-1-christophe.jaillet@wanadoo.fr>
Quoting Christophe JAILLET (2018-05-13 04:17:04)
> We allocate some memory which is neither used, nor referenced by anything.
> So axe it.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
Applied to clk-next
^ permalink raw reply
* [GIT PULL] arm64: defconfig: hisilicon config updates for v4.18
From: Olof Johansson @ 2018-05-15 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180515082811.GL29062@mai>
On Tue, May 15, 2018 at 10:28:11AM +0200, Daniel Lezcano wrote:
> On Mon, May 14, 2018 at 01:14:45PM -0700, Olof Johansson wrote:
> > Hi Wei,
> >
> > On Fri, May 11, 2018 at 03:31:38PM +0100, Wei Xu wrote:
> > > Hi Arnd, Hi Olof,
> > >
> > > Please help to pull the following changes.
> > >
> > > About the CLOCK_STUB and the MAILBOX consolidate patch,
> > > Jassi and Stephen have acked it.
> > > Could you let me know how to handle this kind case
> > > if it is not OK to be in this pull?
> >
> > I don't think there's any need to group the Kconfig changes with the defconfig
> > updates here, is there?
>
> I don't have the patches history, but likely this patch should come together with:
>
> https://patchwork.kernel.org/patch/10399799/
> https://patchwork.kernel.org/patch/10399801/
>
> Otherwise the compilation options won't be consistent with what is enabled in
> the DT.
As long as neither side regresses due to the changes, there should be no
problem. Just because a DT node is added in the tree there's no need to
configure the driver. Or am I missing some aspect of it here?
-Olof
^ permalink raw reply
* [PATCH v6 04/11] firmware: xilinx: Add query data API
From: Jolly Shah @ 2018-05-15 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ab9632f5-882d-462d-d830-0316cad56baf@arm.com>
Hi Sudeep,
> -----Original Message-----
> From: Sudeep Holla [mailto:sudeep.holla at arm.com]
> Sent: Tuesday, May 15, 2018 2:34 AM
> To: Jolly Shah <JOLLYS@xilinx.com>; ard.biesheuvel at linaro.org;
> mingo at kernel.org; gregkh at linuxfoundation.org; matt at codeblueprint.co.uk;
> hkallweit1 at gmail.com; keescook at chromium.org;
> dmitry.torokhov at gmail.com; mturquette at baylibre.com;
> sboyd at codeaurora.org; michal.simek at xilinx.com; robh+dt at kernel.org;
> mark.rutland at arm.com; linux-clk at vger.kernel.org
> Cc: Sudeep Holla <sudeep.holla@arm.com>; Rajan Vaja <RAJANV@xilinx.com>;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org
> Subject: Re: [PATCH v6 04/11] firmware: xilinx: Add query data API
>
>
>
> On 14/05/18 20:16, Jolly Shah wrote:
> > HI Sudeep,
> >
>
> [...]
>
> >>
> >> 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.
> >>
> >
> > This API is used to get clock information from firmware and register
> > clocks accordingly in driver. In our case, firmware maintains database
> > of all clocks available on chip. DT will provide information for off
> > chip reference clocks only. This is to avoid duplication of clocks
> > data in DT and firmware both as firmware anyways need clock data to
> > manage them.
> >
>
> I wanted to understand the difference with example. What kind of information
> you get from DT and what you get from firmware ?
>
> --
> Regards,
> Sudeep
Below is an example showing PLL and Leaf clock derivation:
Input ref clocks->Mux->Multiplier/Divider->PLL*
Pll1/pll2/pll3/pll4->Mux->Divider->Gate->Leaf clock1
Here Off chip input ref clock information comes from DT.
Rest information for Pll/leaf clocks come from firmware using query API. For clock driver, query API is used to get topology, flags, parents etc information per clock.
Thanks,
Jolly Shah
^ permalink raw reply
* [xlnx:master 1122/1651] drivers/dma//xilinx/xilinx_ps_pcie_platform.c:2957:14: error: 'DMA_SG' undeclared; did you mean 'DMA_PQ'?
From: kbuild test robot @ 2018-05-15 20:17 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/Xilinx/linux-xlnx master
head: c3ad4b9f92cef73b118446312f39f2dbe9fc0ff1
commit: 818f168696f561c127f161379eb5b8d1835218a2 [1122/1651] Merge tag 'v4.14' into master
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 818f168696f561c127f161379eb5b8d1835218a2
# save the attached .config to linux build tree
make ARCH=x86_64
Note: the xlnx/master HEAD c3ad4b9f92cef73b118446312f39f2dbe9fc0ff1 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
In file included from drivers/net/ethernet/cadence/macb_pci.c:29:0:
>> drivers/net/ethernet/cadence/macb.h:927:2: error: unknown type name 'phy_interface_t'
phy_interface_t phy_interface;
^~~~~~~~~~~~~~~
>> drivers/net/ethernet/cadence/macb.h:943:24: error: field 'ptp_caps' has incomplete type
struct ptp_clock_info ptp_caps;
^~~~~~~~
--
>> drivers/media//platform/xilinx/xilinx-csi2rxss.c:43:10: fatal error: media/v4l2-of.h: No such file or directory
#include <media/v4l2-of.h>
^~~~~~~~~~~~~~~~~
compilation terminated.
--
In file included from drivers/dma//xilinx/xilinx_ps_pcie.h:16:0,
from drivers/dma//xilinx/xilinx_ps_pcie_platform.c:15:
drivers/dma//xilinx/xilinx_ps_pcie_platform.c: In function 'xlnx_pcie_dma_driver_probe':
>> drivers/dma//xilinx/xilinx_ps_pcie_platform.c:2957:14: error: 'DMA_SG' undeclared (first use in this function); did you mean 'DMA_PQ'?
dma_cap_set(DMA_SG, xdev->common.cap_mask);
^
include/linux/dmaengine.h:1201:46: note: in definition of macro 'dma_cap_set'
#define dma_cap_set(tx, mask) __dma_cap_set((tx), &(mask))
^~
drivers/dma//xilinx/xilinx_ps_pcie_platform.c:2957:14: note: each undeclared identifier is reported only once for each function it appears in
dma_cap_set(DMA_SG, xdev->common.cap_mask);
^
include/linux/dmaengine.h:1201:46: note: in definition of macro 'dma_cap_set'
#define dma_cap_set(tx, mask) __dma_cap_set((tx), &(mask))
^~
>> drivers/dma//xilinx/xilinx_ps_pcie_platform.c:2972:15: error: 'struct dma_device' has no member named 'device_prep_dma_sg'; did you mean 'device_prep_dma_pq'?
xdev->common.device_prep_dma_sg = xlnx_ps_pcie_dma_prep_dma_sg;
^~~~~~~~~~~~~~~~~~
device_prep_dma_pq
--
drivers/dma//xilinx/xilinx_ps_pcie_dma_client.c: In function 'initiate_sync_transfer':
>> drivers/dma//xilinx/xilinx_ps_pcie_dma_client.c:310:17: error: 'struct dma_device' has no member named 'device_prep_dma_sg'; did you mean 'device_prep_dma_pq'?
txd = device->device_prep_dma_sg(chan, dst_sg->sgl,
^~~~~~~~~~~~~~~~~~
device_prep_dma_pq
drivers/dma//xilinx/xilinx_ps_pcie_dma_client.c: In function 'initiate_async_transfer':
drivers/dma//xilinx/xilinx_ps_pcie_dma_client.c:697:17: error: 'struct dma_device' has no member named 'device_prep_dma_sg'; did you mean 'device_prep_dma_pq'?
txd = device->device_prep_dma_sg(chan, dst_sg->sgl,
^~~~~~~~~~~~~~~~~~
device_prep_dma_pq
vim +2957 drivers/dma//xilinx/xilinx_ps_pcie_platform.c
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2909
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2910 xdev->is_rootdma = device_property_read_bool(&platform_dev->dev,
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2911 "rootdma");
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2912
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2913 xdev->dev = &platform_dev->dev;
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2914 xdev->board_number = board_number;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2915
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2916 err = device_property_read_u32(&platform_dev->dev, "numchannels",
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2917 &xdev->num_channels);
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2918 if (err) {
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2919 dev_err(&platform_dev->dev,
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2920 "Unable to find numchannels property\n");
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2921 goto platform_driver_probe_return;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2922 }
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2923
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2924 if (xdev->num_channels == 0 || xdev->num_channels >
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2925 MAX_ALLOWED_CHANNELS_IN_HW) {
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2926 dev_warn(&platform_dev->dev,
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2927 "Invalid xlnx-num_channels property value\n");
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2928 xdev->num_channels = MAX_ALLOWED_CHANNELS_IN_HW;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2929 }
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2930
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2931 xdev->channels =
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2932 (struct ps_pcie_dma_chan *)devm_kzalloc(&platform_dev->dev,
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2933 sizeof(struct ps_pcie_dma_chan)
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2934 * xdev->num_channels,
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2935 GFP_KERNEL);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2936 if (!xdev->channels) {
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2937 err = -ENOMEM;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2938 goto platform_driver_probe_return;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2939 }
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2940
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2941 if (xdev->is_rootdma)
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2942 err = read_rootdma_config(platform_dev, xdev);
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2943 else
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2944 err = read_epdma_config(platform_dev, xdev);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2945
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2946 if (err) {
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2947 dev_err(&platform_dev->dev,
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2948 "Unable to initialize dma configuration\n");
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2949 goto platform_driver_probe_return;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2950 }
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2951
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2952 /* Initialize the DMA engine */
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2953 INIT_LIST_HEAD(&xdev->common.channels);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2954
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2955 dma_cap_set(DMA_SLAVE, xdev->common.cap_mask);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2956 dma_cap_set(DMA_PRIVATE, xdev->common.cap_mask);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 @2957 dma_cap_set(DMA_SG, xdev->common.cap_mask);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2958 dma_cap_set(DMA_INTERRUPT, xdev->common.cap_mask);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2959
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2960 xdev->common.src_addr_widths = DMA_SLAVE_BUSWIDTH_UNDEFINED;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2961 xdev->common.dst_addr_widths = DMA_SLAVE_BUSWIDTH_UNDEFINED;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2962 xdev->common.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2963 xdev->common.device_alloc_chan_resources =
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2964 xlnx_ps_pcie_dma_alloc_chan_resources;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2965 xdev->common.device_free_chan_resources =
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2966 xlnx_ps_pcie_dma_free_chan_resources;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2967 xdev->common.device_terminate_all = xlnx_ps_pcie_dma_terminate_all;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2968 xdev->common.device_tx_status = dma_cookie_status;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2969 xdev->common.device_issue_pending = xlnx_ps_pcie_dma_issue_pending;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2970 xdev->common.device_prep_dma_interrupt =
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2971 xlnx_ps_pcie_dma_prep_interrupt;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 @2972 xdev->common.device_prep_dma_sg = xlnx_ps_pcie_dma_prep_dma_sg;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2973 xdev->common.device_prep_slave_sg = xlnx_ps_pcie_dma_prep_slave_sg;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2974 xdev->common.residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2975
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2976 for (i = 0; i < xdev->num_channels; i++) {
8ddb7910 Ravi Shankar Jonnalagadda 2017-05-12 2977 err = probe_channel_properties(platform_dev, xdev, i);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2978
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2979 if (err != 0) {
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2980 dev_err(xdev->dev,
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2981 "Unable to read channel properties\n");
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2982 goto platform_driver_probe_return;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2983 }
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2984 }
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2985
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2986 if (xdev->is_rootdma)
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2987 err = platform_irq_setup(xdev);
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2988 else
8ddb7910 Ravi Shankar Jonnalagadda 2017-05-12 2989 err = irq_setup(xdev);
8ddb7910 Ravi Shankar Jonnalagadda 2017-05-12 2990 if (err) {
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2991 dev_err(xdev->dev, "Cannot request irq lines for device %d\n",
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2992 xdev->board_number);
8ddb7910 Ravi Shankar Jonnalagadda 2017-05-12 2993 goto platform_driver_probe_return;
8ddb7910 Ravi Shankar Jonnalagadda 2017-05-12 2994 }
8ddb7910 Ravi Shankar Jonnalagadda 2017-05-12 2995
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2996 err = dma_async_device_register(&xdev->common);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2997 if (err) {
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 2998 dev_err(xdev->dev,
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 2999 "Unable to register board %d with dma framework\n",
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 3000 xdev->board_number);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3001 goto platform_driver_probe_return;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3002 }
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3003
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3004 platform_set_drvdata(platform_dev, xdev);
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3005
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 3006 board_number++;
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 3007
5b2dbdec Ravi Shankar Jonnalagadda 2017-08-08 3008 dev_info(&platform_dev->dev, "PS PCIe Platform driver probed\n");
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3009 return 0;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3010
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3011 platform_driver_probe_return:
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3012 return err;
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3013 }
361e9379 Ravi Shankar Jonnalagadda 2017-04-28 3014
:::::: The code at line 2957 was first introduced by commit
:::::: 361e937922b2073151335141bcd67b37f46b52fb PCI: ZYNQMP EP driver: Adding support for ZynqMP ep driver
:::::: TO: Ravi Shankar Jonnalagadda <venkata.ravi.jonnalagadda@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: 61983 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180516/69687a2f/attachment-0001.gz>
^ 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