Re: [PATCH 3/4] irqchip/mbigen: add support for a MBIGEN generating SPIs

Hi Marc, >>> Now, the biggest question of them all: how does it work with ACPI? Last >>> time I checked, there was no DT support for platforms using the MBIGEN. >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/hisilicon/hip07.dtsi >> This DT

Re: [PATCH 3/4] irqchip/mbigen: add support for a MBIGEN generating SPIs

Hi Marc, >>> Now, the biggest question of them all: how does it work with ACPI? Last >>> time I checked, there was no DT support for platforms using the MBIGEN. >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/hisilicon/hip07.dtsi >> This DT

Re: [PATCH 1/2] arm64: avoid alloc memory on offline node

On 2018/6/20 19:51, Punit Agrawal wrote: > Xie XiuQi writes: > >> Hi Lorenzo, Punit, >> >> >> On 2018/6/20 0:32, Lorenzo Pieralisi wrote: >>> On Tue, Jun 19, 2018 at 04:35:40PM +0100, Punit Agrawal wrote: Michal Hocko writes: > On Tue 19-06-18 15:54:26, Punit Agrawal wrote: >

Re: [PATCH 1/2] arm64: avoid alloc memory on offline node

On 2018/6/20 19:51, Punit Agrawal wrote: > Xie XiuQi writes: > >> Hi Lorenzo, Punit, >> >> >> On 2018/6/20 0:32, Lorenzo Pieralisi wrote: >>> On Tue, Jun 19, 2018 at 04:35:40PM +0100, Punit Agrawal wrote: Michal Hocko writes: > On Tue 19-06-18 15:54:26, Punit Agrawal wrote: >

Re: [PATCH 1/2] arm64: avoid alloc memory on offline node

Hi Punit, On 2018/6/14 1:39, Punit Agrawal wrote: > Punit Agrawal writes: > > > [...] > >> >> CONFIG_HAVE_MEMORYLESS node is not enabled on arm64 which means we end >> up returning the original node in the fallback path. >> >> Xie, does the below patch help? I can submit a proper patch if

Re: [PATCH 1/2] arm64: avoid alloc memory on offline node

Hi Punit, On 2018/6/14 1:39, Punit Agrawal wrote: > Punit Agrawal writes: > > > [...] > >> >> CONFIG_HAVE_MEMORYLESS node is not enabled on arm64 which means we end >> up returning the original node in the fallback path. >> >> Xie, does the below patch help? I can submit a proper patch if

Re: [PATCH v2] irqchip/gic-v3-its: fix ITS queue timeout

Hi Marc, On 2018/6/6 17:13, Marc Zyngier wrote: [...] > > Wouldn't it be better to just return that the affinity setting request > is impossible to satisfy? And more to the point, how comes we end-up > in such a case? The system is booted with a NUMA node has no memory attaching to it

Re: [PATCH v2] irqchip/gic-v3-its: fix ITS queue timeout

Hi Marc, On 2018/6/6 17:13, Marc Zyngier wrote: [...] > > Wouldn't it be better to just return that the affinity setting request > is impossible to satisfy? And more to the point, how comes we end-up > in such a case? The system is booted with a NUMA node has no memory attaching to it

Re: [PATCH 1/2] arm64: avoid alloc memory on offline node

.928426] pci_acpi_scan_root+0x94/0x278 >>>> [ 25.932510] acpi_pci_root_add+0x228/0x4b0 >>>> [ 25.936593] acpi_bus_attach+0x10c/0x218 >>>> [ 25.940501] acpi_bus_attach+0xac/0x218 >>>> [ 25.944323] acpi_bus_attach+0xac/0x218 >>>

Re: [PATCH 1/2] arm64: avoid alloc memory on offline node

.928426] pci_acpi_scan_root+0x94/0x278 >>>> [ 25.932510] acpi_pci_root_add+0x228/0x4b0 >>>> [ 25.936593] acpi_bus_attach+0x10c/0x218 >>>> [ 25.940501] acpi_bus_attach+0xac/0x218 >>>> [ 25.944323] acpi_bus_attach+0xac/0x218 >>>

Re: [PATCH 0/2] arm64/drivers: avoid alloc memory on offline node

Hi Xiuqi, On 2018/5/31 20:14, Xie XiuQi wrote: > A numa system may return node which is not online. > For example, a numa node: > 1) without memory > 2) NR_CPUS is very small, and the cpus on the node are not brought up I think adding detail info will be easy to be understood: - NUMA node will

Re: [PATCH 0/2] arm64/drivers: avoid alloc memory on offline node

Hi Xiuqi, On 2018/5/31 20:14, Xie XiuQi wrote: > A numa system may return node which is not online. > For example, a numa node: > 1) without memory > 2) NR_CPUS is very small, and the cpus on the node are not brought up I think adding detail info will be easy to be understood: - NUMA node will

Re: [PATCH 2/2] perf: add arm64 smmuv3 pmu driver

[+Cc Lorenzo] Hi Neil, On 2018/4/3 1:59, Neil Leeder wrote: > Hi Hanjun, > > On 4/2/2018 10:24 AM, Hanjun Guo wrote: > >> >> I think we need to wait for the new version of IORT spec, >> which includes the fix for the two base address for SMMUv3 >> PMCG (n

Re: [PATCH 2/2] perf: add arm64 smmuv3 pmu driver

[+Cc Lorenzo] Hi Neil, On 2018/4/3 1:59, Neil Leeder wrote: > Hi Hanjun, > > On 4/2/2018 10:24 AM, Hanjun Guo wrote: > >> >> I think we need to wait for the new version of IORT spec, >> which includes the fix for the two base address for SMMUv3 >> PMCG (n

Re: [PATCH 2/2] perf: add arm64 smmuv3 pmu driver

On 2018/4/2 14:37, Yisheng Xie wrote: > Hi Neil, > > On 2018/4/1 13:44, Neil Leeder wrote: >> Hi Yisheng Xie, >> >> On 3/29/2018 03:03 AM, Yisheng Xie wrote: >>> >>> Hi Neil, >>> >>> On 2017/8/5 3:59, Neil Leeder wrote: +mem_resource_0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);

Re: [PATCH 2/2] perf: add arm64 smmuv3 pmu driver

On 2018/4/2 14:37, Yisheng Xie wrote: > Hi Neil, > > On 2018/4/1 13:44, Neil Leeder wrote: >> Hi Yisheng Xie, >> >> On 3/29/2018 03:03 AM, Yisheng Xie wrote: >>> >>> Hi Neil, >>> >>> On 2017/8/5 3:59, Neil Leeder wrote: +mem_resource_0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);

Re: [PATCH v4] ACPI / tables: Add IORT to injectable table list

Cc: Joey Zheng <yu.zh...@hxt-semitech.com> > Cc: Wang Dongsheng <dongsheng.w...@hxt-semitech.com> > Cc: Jiang Yutang <yutang2.ji...@hxt-semitech.com> > Cc: Hanjun Guo <guohan...@huawei.com> > Signed-off-by: Yang Shunyong <shunyong.y...@hxt-semitech.com> Acked-by: Hanjun Guo <hanjun@linaro.org> Thanks Hanjun

Re: [PATCH v4] ACPI / tables: Add IORT to injectable table list

Cc: Joey Zheng > Cc: Wang Dongsheng > Cc: Jiang Yutang > Cc: Hanjun Guo > Signed-off-by: Yang Shunyong Acked-by: Hanjun Guo Thanks Hanjun

Re: [PATCH v3] ACPI / tables: Add IORT to injectable table list

> from initrd to override which from firmware. > > Signed-off-by: Yang Shunyong <shunyong.y...@hxt-semitech.com> > Cc: Joey Zheng <yu.zh...@hxt-semitech.com> > Cc: Wang Dongsheng <dongsheng.w...@hxt-semitech.com> > Cc: Jiang Yutang <yutang2.ji...@hxt-semitech.c

Re: [PATCH v3] ACPI / tables: Add IORT to injectable table list

> from initrd to override which from firmware. > > Signed-off-by: Yang Shunyong > Cc: Joey Zheng > Cc: Wang Dongsheng > Cc: Jiang Yutang > Cc: Hanjun Guo With that updated, Acked-by: Hanjun Guo Thanks Hanjun

Re: [PATCH v3 18/18] arm64: Kill PSCI_GET_VERSION as a variant-2 workaround

Hi Marc, Thank you for keeping me in the loop, just minor comments below. On 2018/2/1 19:46, Marc Zyngier wrote: > Now that we've standardised on SMCCC v1.1 to perform the branch > prediction invalidation, let's drop the previous band-aid. > If vendors haven't updated their firmware to do SMCCC

Re: [PATCH v3 18/18] arm64: Kill PSCI_GET_VERSION as a variant-2 workaround

Hi Marc, Thank you for keeping me in the loop, just minor comments below. On 2018/2/1 19:46, Marc Zyngier wrote: > Now that we've standardised on SMCCC v1.1 to perform the branch > prediction invalidation, let's drop the previous band-aid. > If vendors haven't updated their firmware to do SMCCC

Re: [PATCH v2 16/16] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

On 2018/2/1 16:53, Marc Zyngier wrote: [...] ... and actually, perhaps it makes sense for the SMCCC_ARCH_WORKAROUND_1 check to be completely independent of MIDR based errata matching? I.e., if SMCCC v1.1 and SMCCC_ARCH_WORKAROUND_1 are both implemented, we should

Re: [PATCH v2 16/16] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

On 2018/2/1 16:53, Marc Zyngier wrote: [...] ... and actually, perhaps it makes sense for the SMCCC_ARCH_WORKAROUND_1 check to be completely independent of MIDR based errata matching? I.e., if SMCCC v1.1 and SMCCC_ARCH_WORKAROUND_1 are both implemented, we should

Re: [PATCH v2 16/16] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

On 2018/2/1 10:40, Hanjun Guo wrote: > On 2018/1/31 23:05, Marc Zyngier wrote: >> On 31/01/18 14:38, Ard Biesheuvel wrote: >>> On 31 January 2018 at 14:35, Ard Biesheuvel <ard.biesheu...@linaro.org> >>> wrote: >>>> On 31 January 2018 at 14:

Re: [PATCH v2 16/16] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

On 2018/2/1 10:40, Hanjun Guo wrote: > On 2018/1/31 23:05, Marc Zyngier wrote: >> On 31/01/18 14:38, Ard Biesheuvel wrote: >>> On 31 January 2018 at 14:35, Ard Biesheuvel >>> wrote: >>>> On 31 January 2018 at 14:11, Marc Zyngier wrote: >>>>&g

Re: [PATCH v2 16/16] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

On 2018/1/31 23:05, Marc Zyngier wrote: > On 31/01/18 14:38, Ard Biesheuvel wrote: >> On 31 January 2018 at 14:35, Ard Biesheuvel <ard.biesheu...@linaro.org> >> wrote: >>> On 31 January 2018 at 14:11, Marc Zyngier <marc.zyng...@arm.com> wrote: >>>&g

Re: [PATCH v2 16/16] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

On 2018/1/31 23:05, Marc Zyngier wrote: > On 31/01/18 14:38, Ard Biesheuvel wrote: >> On 31 January 2018 at 14:35, Ard Biesheuvel >> wrote: >>> On 31 January 2018 at 14:11, Marc Zyngier wrote: >>>> On 31/01/18 13:56, Hanjun Guo wrote: >>>>> H

Re: [PATCH v2 16/16] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

Hi Marc, On 2018/1/30 1:45, Marc Zyngier wrote: > static int enable_psci_bp_hardening(void *data) > { > const struct arm64_cpu_capabilities *entry = data; > > - if (psci_ops.get_version) > + if (psci_ops.get_version) { > + if (check_smccc_arch_workaround_1(entry)) >

Re: [PATCH v2 16/16] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

Hi Marc, On 2018/1/30 1:45, Marc Zyngier wrote: > static int enable_psci_bp_hardening(void *data) > { > const struct arm64_cpu_capabilities *entry = data; > > - if (psci_ops.get_version) > + if (psci_ops.get_version) { > + if (check_smccc_arch_workaround_1(entry)) >

Re: [PATCH v2] ACPI / tables: Add IORT to injectable table list

Hi Shunyong, On 2018/1/30 9:44, Yang, Shunyong wrote: > Hi, Rafael > > Could you please help to review this patch? This is a small change to > add ACPI_SIG_IORT to table_sigs[].  > Loading IORT table from initrd is very useful to debug SMMU node/device > probe, MSI allocation, stream id

Re: [PATCH v2] ACPI / tables: Add IORT to injectable table list

Hi Shunyong, On 2018/1/30 9:44, Yang, Shunyong wrote: > Hi, Rafael > > Could you please help to review this patch? This is a small change to > add ACPI_SIG_IORT to table_sigs[].  > Loading IORT table from initrd is very useful to debug SMMU node/device > probe, MSI allocation, stream id

Re: [PATCH 04/18] arm: implement nospec_ptr()

On 2018/1/10 10:04, Laura Abbott wrote: > On 01/05/2018 05:10 PM, Dan Williams wrote: >> From: Mark Rutland >> >> This patch implements nospec_ptr() for arm, following the recommended >> architectural sequences for the arm and thumb instruction sets. >> > Fedora picked up

Re: [PATCH 04/18] arm: implement nospec_ptr()

On 2018/1/10 10:04, Laura Abbott wrote: > On 01/05/2018 05:10 PM, Dan Williams wrote: >> From: Mark Rutland >> >> This patch implements nospec_ptr() for arm, following the recommended >> architectural sequences for the arm and thumb instruction sets. >> > Fedora picked up the series and it fails

Re: [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero

On 2018/1/6 6:15, Kani, Toshi wrote: > On Thu, 2017-12-28 at 19:24 +0800, Hanjun Guo wrote: >> From: Hanjun Guo <hanjun@linaro.org> >> >> When we using iounmap() to free the 4K mapping, it just clear the PTEs >> but leave P4D/PUD/PMD unchanged, also will not

Re: [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero

On 2018/1/6 6:15, Kani, Toshi wrote: > On Thu, 2017-12-28 at 19:24 +0800, Hanjun Guo wrote: >> From: Hanjun Guo >> >> When we using iounmap() to free the 4K mapping, it just clear the PTEs >> but leave P4D/PUD/PMD unchanged, also will not free the memory of page >&

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

On 2018/1/6 15:55, Dave Hansen wrote: > On 01/05/2018 10:53 PM, Hanjun Guo wrote: >>> + /* >>> + * PTI poisons low addresses in the kernel page tables in the >>> + * name of making them unusable for userspace. To execute >>> + * code at such a

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

On 2018/1/6 15:55, Dave Hansen wrote: > On 01/05/2018 10:53 PM, Hanjun Guo wrote: >>> + /* >>> + * PTI poisons low addresses in the kernel page tables in the >>> + * name of making them unusable for userspace. To execute >>> + * code at such a

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

On 2018/1/6 14:28, Hanjun Guo wrote: > Hi Dave, > > Thank you very much for the quick response! Minor comments inline. > > On 2018/1/6 14:06, Dave Hansen wrote: >> On 01/05/2018 08:54 PM, Hanjun Guo wrote: >>> Do you mean NX bit will be brought back later? I'm as

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

On 2018/1/6 14:28, Hanjun Guo wrote: > Hi Dave, > > Thank you very much for the quick response! Minor comments inline. > > On 2018/1/6 14:06, Dave Hansen wrote: >> On 01/05/2018 08:54 PM, Hanjun Guo wrote: >>> Do you mean NX bit will be brought back later? I'm as

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

Hi Dave, Thank you very much for the quick response! Minor comments inline. On 2018/1/6 14:06, Dave Hansen wrote: > On 01/05/2018 08:54 PM, Hanjun Guo wrote: >> Do you mean NX bit will be brought back later? I'm asking this because >> I tested this patch which it fixed the b

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

Hi Dave, Thank you very much for the quick response! Minor comments inline. On 2018/1/6 14:06, Dave Hansen wrote: > On 01/05/2018 08:54 PM, Hanjun Guo wrote: >> Do you mean NX bit will be brought back later? I'm asking this because >> I tested this patch which it fixed the b

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

Hi Jiri, Thanks for the fix, comments inline. On 2018/1/6 2:19, Jiri Kosina wrote: > > [ adding Hugh ] > > On Thu, 4 Jan 2018, Dave Hansen wrote: > >>> BTW, we have just reported a bug caused by kaiser[1], which looks like >>> caused by SMEP. Could you please help to have a look? >>> >>> [1]

Re: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

Hi Jiri, Thanks for the fix, comments inline. On 2018/1/6 2:19, Jiri Kosina wrote: > > [ adding Hugh ] > > On Thu, 4 Jan 2018, Dave Hansen wrote: > >>> BTW, we have just reported a bug caused by kaiser[1], which looks like >>> caused by SMEP. Could you please help to have a look? >>> >>> [1]

Re: [RFC] does ioremap() cause memory leak?

On 2017/12/23 13:32, Xishi Qiu wrote: > On 2017/12/21 16:55, Xishi Qiu wrote: > >> When we use iounmap() to free the mapping, it calls unmap_vmap_area() to >> clear page table, >> but do not free the memory of page table, right? >> >> So when use ioremap() to mapping another area(incluce the

Re: [RFC] does ioremap() cause memory leak?

On 2017/12/23 13:32, Xishi Qiu wrote: > On 2017/12/21 16:55, Xishi Qiu wrote: > >> When we use iounmap() to free the mapping, it calls unmap_vmap_area() to >> clear page table, >> but do not free the memory of page table, right? >> >> So when use ioremap() to mapping another area(incluce the

Re: [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero

oops, the title of this patch is wrong, should be: ioremap: skip setting up huge I/O mappings when p4d/pud/pmd is zero On 2017/12/28 19:24, Hanjun Guo wrote: > From: Hanjun Guo <hanjun@linaro.org> > > When we using iounmap() to free the 4K mapping, it just clear the PTEs >

Re: [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero

oops, the title of this patch is wrong, should be: ioremap: skip setting up huge I/O mappings when p4d/pud/pmd is zero On 2017/12/28 19:24, Hanjun Guo wrote: > From: Hanjun Guo > > When we using iounmap() to free the 4K mapping, it just clear the PTEs > but leave P4D/PUD/PMD unc

[RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero

From: Hanjun Guo <hanjun@linaro.org> When we using iounmap() to free the 4K mapping, it just clear the PTEs but leave P4D/PUD/PMD unchanged, also will not free the memory of page tables. This will cause issues on ARM64 platform (not sure if other archs have the same issue) for this ca

[RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero

From: Hanjun Guo When we using iounmap() to free the 4K mapping, it just clear the PTEs but leave P4D/PUD/PMD unchanged, also will not free the memory of page tables. This will cause issues on ARM64 platform (not sure if other archs have the same issue) for this case: 1. ioremap a 4K size

Re: [PATCH V3 net-next 00/17] add some features and fix some bugs for HNS3 driver

On 2017/12/21 10:27, lipeng (Y) wrote: > > > On 2017/12/21 3:28, David Miller wrote: >> From: Lipeng >> Date: Wed, 20 Dec 2017 16:43:02 +0800 >> >>> This patchset adds some new feature support and fixes some bugs: >>> [Patch 1/17 - 5/17] add the support to modify/query the

Re: [PATCH V3 net-next 00/17] add some features and fix some bugs for HNS3 driver

On 2017/12/21 10:27, lipeng (Y) wrote: > > > On 2017/12/21 3:28, David Miller wrote: >> From: Lipeng >> Date: Wed, 20 Dec 2017 16:43:02 +0800 >> >>> This patchset adds some new feature support and fixes some bugs: >>> [Patch 1/17 - 5/17] add the support to modify/query the tqp number >>>

Re: linux-next: Signed-off-by missing for commit in the rcu tree

Hi Lihao, On 2017/11/29 10:48, Lihao Liang wrote: > Hi Paul, > > Signed-off-by: Lihao Liang ... > > Many thanks, > Lihao. > > On 2017/11/29 9:14, Paul E. McKenney wrote: >> On Wed, Nov 29, 2017 at 11:51:51AM +1100, Stephen Rothwell wrote: >>> Hi Paul, >>> >>> Commit >>>

Re: linux-next: Signed-off-by missing for commit in the rcu tree

Hi Lihao, On 2017/11/29 10:48, Lihao Liang wrote: > Hi Paul, > > Signed-off-by: Lihao Liang ... > > Many thanks, > Lihao. > > On 2017/11/29 9:14, Paul E. McKenney wrote: >> On Wed, Nov 29, 2017 at 11:51:51AM +1100, Stephen Rothwell wrote: >>> Hi Paul, >>> >>> Commit >>> >>> d7e182c9c324

Re: [PATCH v3 2/7] ACPI: Enable PPTT support on ARM64

Hi Jeremy, On 2017/10/13 3:48, Jeremy Linton wrote: > Now that we have a PPTT parser, in preparation for its use > on arm64, lets build it. > > Signed-off-by: Jeremy Linton > --- > arch/arm64/Kconfig | 1 + > drivers/acpi/Makefile | 1 + >

Re: [PATCH v3 2/7] ACPI: Enable PPTT support on ARM64

Hi Jeremy, On 2017/10/13 3:48, Jeremy Linton wrote: > Now that we have a PPTT parser, in preparation for its use > on arm64, lets build it. > > Signed-off-by: Jeremy Linton > --- > arch/arm64/Kconfig | 1 + > drivers/acpi/Makefile | 1 + > drivers/acpi/arm64/Kconfig | 3 +++ > 3

Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support

On 2017/10/12 19:05, Lorenzo Pieralisi wrote: > On Thu, Oct 12, 2017 at 06:58:33PM +0800, Hanjun Guo wrote: >> On 2017/8/11 11:28, Leeder, Neil wrote: >>> On 8/9/2017 9:26 PM, Hanjun Guo wrote: >>>>> On 2017/8/9 23:48, Leeder, Neil wrote: >>>>&

Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support

On 2017/10/12 19:05, Lorenzo Pieralisi wrote: > On Thu, Oct 12, 2017 at 06:58:33PM +0800, Hanjun Guo wrote: >> On 2017/8/11 11:28, Leeder, Neil wrote: >>> On 8/9/2017 9:26 PM, Hanjun Guo wrote: >>>>> On 2017/8/9 23:48, Leeder, Neil wrote: >>>>&

Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support

On 2017/8/11 11:28, Leeder, Neil wrote: > On 8/9/2017 9:26 PM, Hanjun Guo wrote: >> > On 2017/8/9 23:48, Leeder, Neil wrote: >>>>> >>>>drivers/perf/Kconfig | 9 + >>>>> >>>>drivers/perf/Makefile

Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support

On 2017/8/11 11:28, Leeder, Neil wrote: > On 8/9/2017 9:26 PM, Hanjun Guo wrote: >> > On 2017/8/9 23:48, Leeder, Neil wrote: >>>>> >>>>drivers/perf/Kconfig | 9 + >>>>> >>>>drivers/perf/Makefile

Re: [PATCH v2] acpi/arm64: pr_err() strings should end with newlines

pr_err(FW_BUG "GT block present, but frame count is zero.\n"); > return -ENODEV; > } > Make sense to me, Acked-by: Hanjun Guo <hanjun@linaro.org> Lorenzo, could you pick this up for 4.15? Thanks Hanjun

Re: [PATCH v2] acpi/arm64: pr_err() strings should end with newlines

t, but frame count is zero.\n"); > return -ENODEV; > } > Make sense to me, Acked-by: Hanjun Guo Lorenzo, could you pick this up for 4.15? Thanks Hanjun

Re: [PATCH] tee: ACPI support for optee driver

On 2017/9/21 15:12, Mayuresh Chitale wrote: > This patch modifies the optee driver to add support for parsing > the conduit method from an ACPI node. Sorry I didn't involve this earlier, but I think this is a wrong approach, in ACPI 5.1+ spec, there is a bit in FADT table which indicates PSCI

Re: [PATCH] tee: ACPI support for optee driver

On 2017/9/21 15:12, Mayuresh Chitale wrote: > This patch modifies the optee driver to add support for parsing > the conduit method from an ACPI node. Sorry I didn't involve this earlier, but I think this is a wrong approach, in ACPI 5.1+ spec, there is a bit in FADT table which indicates PSCI

Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

On 2017/8/31 16:20, Yisheng Xie wrote: Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3: https://www.spinics.net/lists/arm-kernel/msg565155.html But for some platform devices(aka on-chip integrated devices), there is also SVM requirement, which works based on the SMMU

Re: [RFC PATCH 0/6] Add platform device SVM support for ARM SMMUv3

On 2017/8/31 16:20, Yisheng Xie wrote: Jean-Philippe has post a patchset for Adding PCIe SVM support to ARM SMMUv3: https://www.spinics.net/lists/arm-kernel/msg565155.html But for some platform devices(aka on-chip integrated devices), there is also SVM requirement, which works based on the SMMU

Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support

On 2017/8/9 23:48, Leeder, Neil wrote: drivers/perf/Kconfig | 9 + drivers/perf/Makefile | 1 + drivers/perf/arm_smmuv3_pmu.c | 823 ++ include/acpi/actbl2.h | 9 +- Do you have the acpica support code? I'm

Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support

On 2017/8/9 23:48, Leeder, Neil wrote: drivers/perf/Kconfig | 9 + drivers/perf/Makefile | 1 + drivers/perf/arm_smmuv3_pmu.c | 823 ++ include/acpi/actbl2.h | 9 +- Do you have the acpica support code? I'm

Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support

Hi Neil, On 2017/8/5 3:59, Neil Leeder wrote: This adds a driver for the SMMUv3 PMU into the perf framework. It includes an IORT update to support PM Counter Groups. IORT has no mechanism for determining device names so PMUs are named based on their physical address. Tested on Qualcomm

Re: [PATCH 0/2] arm64 SMMUv3 PMU driver with IORT support

Hi Neil, On 2017/8/5 3:59, Neil Leeder wrote: This adds a driver for the SMMUv3 PMU into the perf framework. It includes an IORT update to support PM Counter Groups. IORT has no mechanism for determining device names so PMUs are named based on their physical address. Tested on Qualcomm

Re: [PATCH v3] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

On 2017/7/26 18:15, Hanjun Guo wrote: From: Hanjun Guo <hanjun@linaro.org> When enabling ITS NUMA support on D05, I got the boot log: [0.00] SRAT: PXM 0 -> ITS 0 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 1 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 2 -&

Re: [PATCH v3] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

On 2017/7/26 18:15, Hanjun Guo wrote: From: Hanjun Guo When enabling ITS NUMA support on D05, I got the boot log: [0.00] SRAT: PXM 0 -> ITS 0 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 1 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 2 -> Node 0 [0.00] SR

Re: [PATCH v4] acpi/iort: numa: Add numa node mapping for smmuv3 devices

On 2017/8/3 21:35, Hanjun Guo wrote: > On 2017/8/3 0:21, Lorenzo Pieralisi wrote: >> > Patch that I will send upstream below, please check, thanks. >> > >> > -- >8 -- >> > Subject: [PATCH] ACPI/IORT: numa: Add numa node mapping for smmuv3 devices >>

Re: [PATCH v4] acpi/iort: numa: Add numa node mapping for smmuv3 devices

On 2017/8/3 21:35, Hanjun Guo wrote: > On 2017/8/3 0:21, Lorenzo Pieralisi wrote: >> > Patch that I will send upstream below, please check, thanks. >> > >> > -- >8 -- >> > Subject: [PATCH] ACPI/IORT: numa: Add numa node mapping for smmuv3 devices >>

Re: [PATCH v4] acpi/iort: numa: Add numa node mapping for smmuv3 devices

On 2017/8/3 0:21, Lorenzo Pieralisi wrote: > Patch that I will send upstream below, please check, thanks. > > -- >8 -- > Subject: [PATCH] ACPI/IORT: numa: Add numa node mapping for smmuv3 devices > > ARM IORT specification(rev. C) has added provision to define proximity > domain in SMMUv3 IORT

Re: [PATCH v4] acpi/iort: numa: Add numa node mapping for smmuv3 devices

On 2017/8/3 0:21, Lorenzo Pieralisi wrote: > Patch that I will send upstream below, please check, thanks. > > -- >8 -- > Subject: [PATCH] ACPI/IORT: numa: Add numa node mapping for smmuv3 devices > > ARM IORT specification(rev. C) has added provision to define proximity > domain in SMMUv3 IORT

Re: [PATCH v3 0/5] ACPI: DMA ranges management

nges for devices and > update their data structures to make them work with their related DMA > addressing restrictions. > > Cc: Will Deacon <will.dea...@arm.com> > Cc: Hanjun Guo <hanjun@linaro.org> > Cc: Feng Kan <f...@apm.com> > Cc: Jon Masters <j...@re

Re: [PATCH v3 0/5] ACPI: DMA ranges management

nges for devices and > update their data structures to make them work with their related DMA > addressing restrictions. > > Cc: Will Deacon > Cc: Hanjun Guo > Cc: Feng Kan > Cc: Jon Masters > Cc: Robert Moore > Cc: Robin Murphy > Cc: Zhang Rui > Cc: "

Re: [PATCH v2 5/5] ACPI/IORT: Add IORT named component memory address limits

On 2017/8/1 19:21, Lorenzo Pieralisi wrote: On Tue, Aug 01, 2017 at 06:20:43PM +0800, Hanjun Guo wrote: Hi Lorenzo, On 2017/7/31 23:23, Lorenzo Pieralisi wrote: IORT named components provide firmware configuration describing how many address bits a given device is capable of generating

Re: [PATCH v2 5/5] ACPI/IORT: Add IORT named component memory address limits

On 2017/8/1 19:21, Lorenzo Pieralisi wrote: On Tue, Aug 01, 2017 at 06:20:43PM +0800, Hanjun Guo wrote: Hi Lorenzo, On 2017/7/31 23:23, Lorenzo Pieralisi wrote: IORT named components provide firmware configuration describing how many address bits a given device is capable of generating

Re: [PATCH v2 5/5] ACPI/IORT: Add IORT named component memory address limits

Hi Lorenzo, On 2017/7/31 23:23, Lorenzo Pieralisi wrote: IORT named components provide firmware configuration describing how many address bits a given device is capable of generating to address memory. Add code to the kernel to retrieve memory address limits configuration for IORT named

Re: [PATCH v2 5/5] ACPI/IORT: Add IORT named component memory address limits

Hi Lorenzo, On 2017/7/31 23:23, Lorenzo Pieralisi wrote: IORT named components provide firmware configuration describing how many address bits a given device is capable of generating to address memory. Add code to the kernel to retrieve memory address limits configuration for IORT named

Re: [PATCH v2] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

Hi Robin, On 2017/7/26 19:05, Robin Murphy wrote: On 26/07/17 09:11, Hanjun Guo wrote: On 2017/7/25 18:47, Lorenzo Pieralisi wrote: On Sat, Jul 22, 2017 at 11:54:12AM +0800, Hanjun Guo wrote: From: Hanjun Guo <hanjun@linaro.org> When running 4.13-rc1 on top of D05, I got the bo

Re: [PATCH v2] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

Hi Robin, On 2017/7/26 19:05, Robin Murphy wrote: On 26/07/17 09:11, Hanjun Guo wrote: On 2017/7/25 18:47, Lorenzo Pieralisi wrote: On Sat, Jul 22, 2017 at 11:54:12AM +0800, Hanjun Guo wrote: From: Hanjun Guo When running 4.13-rc1 on top of D05, I got the boot log: Nit: You should stick

[PATCH v3] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

From: Hanjun Guo <hanjun@linaro.org> When enabling ITS NUMA support on D05, I got the boot log: [0.00] SRAT: PXM 0 -> ITS 0 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 1 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 2 -> Node 0 [0.00] SRAT:

[PATCH v3] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

From: Hanjun Guo When enabling ITS NUMA support on D05, I got the boot log: [0.00] SRAT: PXM 0 -> ITS 0 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 1 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 2 -> Node 0 [0.00] SRAT: PXM 1 -> ITS 3 -> Node 1 [0.00

Re: [PATCH v2] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

On 2017/7/26 18:01, Marc Zyngier wrote: On 26/07/17 10:55, Hanjun Guo wrote: On 2017/7/26 16:00, Marc Zyngier wrote: On 26/07/17 08:52, Hanjun Guo wrote: On 2017/7/25 18:30, Marc Zyngier wrote: On 22/07/17 04:54, Hanjun Guo wrote: From: Hanjun Guo <hanjun@linaro.org> When runnin

Re: [PATCH v2] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

On 2017/7/26 18:01, Marc Zyngier wrote: On 26/07/17 10:55, Hanjun Guo wrote: On 2017/7/26 16:00, Marc Zyngier wrote: On 26/07/17 08:52, Hanjun Guo wrote: On 2017/7/25 18:30, Marc Zyngier wrote: On 22/07/17 04:54, Hanjun Guo wrote: From: Hanjun Guo When running 4.13-rc1 on top of D05, I

Re: [PATCH v2] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

On 2017/7/26 16:00, Marc Zyngier wrote: On 26/07/17 08:52, Hanjun Guo wrote: On 2017/7/25 18:30, Marc Zyngier wrote: On 22/07/17 04:54, Hanjun Guo wrote: From: Hanjun Guo <hanjun@linaro.org> When running 4.13-rc1 on top of D05, I got the boot log: [0.00] SRAT: PXM 0 -&

Re: [PATCH v2] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

On 2017/7/26 16:00, Marc Zyngier wrote: On 26/07/17 08:52, Hanjun Guo wrote: On 2017/7/25 18:30, Marc Zyngier wrote: On 22/07/17 04:54, Hanjun Guo wrote: From: Hanjun Guo When running 4.13-rc1 on top of D05, I got the boot log: [0.00] SRAT: PXM 0 -> ITS 0 -> Node 0 [0.

Re: [PATCH v2] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

On 2017/7/25 19:02, John Garry wrote: On 22/07/2017 04:54, Hanjun Guo wrote: From: Hanjun Guo <hanjun@linaro.org> When running 4.13-rc1 on top of D05, I got the boot log: [0.00] SRAT: PXM 0 -> ITS 0 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 1 -> Node 0 [0.0

Re: [PATCH v2] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

On 2017/7/25 19:02, John Garry wrote: On 22/07/2017 04:54, Hanjun Guo wrote: From: Hanjun Guo When running 4.13-rc1 on top of D05, I got the boot log: [0.00] SRAT: PXM 0 -> ITS 0 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 1 -> Node 0 [0.00] SRAT: PXM 0 ->

Re: [PATCH v2] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

On 2017/7/25 19:02, John Garry wrote: On 22/07/2017 04:54, Hanjun Guo wrote: From: Hanjun Guo <hanjun@linaro.org> When running 4.13-rc1 on top of D05, I got the boot log: [0.00] SRAT: PXM 0 -> ITS 0 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 1 -> Node 0 [0.0

Re: [PATCH v2] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

On 2017/7/25 19:02, John Garry wrote: On 22/07/2017 04:54, Hanjun Guo wrote: From: Hanjun Guo When running 4.13-rc1 on top of D05, I got the boot log: [0.00] SRAT: PXM 0 -> ITS 0 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 1 -> Node 0 [0.00] SRAT: PXM 0 ->

Re: [PATCH v2] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

On 2017/7/25 18:47, Lorenzo Pieralisi wrote: On Sat, Jul 22, 2017 at 11:54:12AM +0800, Hanjun Guo wrote: From: Hanjun Guo <hanjun@linaro.org> When running 4.13-rc1 on top of D05, I got the boot log: Nit: You should stick to what the problem is and why you need to solve it, "

Re: [PATCH v2] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

On 2017/7/25 18:47, Lorenzo Pieralisi wrote: On Sat, Jul 22, 2017 at 11:54:12AM +0800, Hanjun Guo wrote: From: Hanjun Guo When running 4.13-rc1 on top of D05, I got the boot log: Nit: You should stick to what the problem is and why you need to solve it, "Fixes:" tag gives the comm

Re: [PATCH v2] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

On 2017/7/25 18:30, Marc Zyngier wrote: On 22/07/17 04:54, Hanjun Guo wrote: From: Hanjun Guo <hanjun@linaro.org> When running 4.13-rc1 on top of D05, I got the boot log: [0.00] SRAT: PXM 0 -> ITS 0 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 1 -> Node 0 [0.0

Re: [PATCH v2] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

On 2017/7/25 18:30, Marc Zyngier wrote: On 22/07/17 04:54, Hanjun Guo wrote: From: Hanjun Guo When running 4.13-rc1 on top of D05, I got the boot log: [0.00] SRAT: PXM 0 -> ITS 0 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 1 -> Node 0 [0.00] SRAT: PXM 0 ->

[PATCH v2] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

From: Hanjun Guo <hanjun@linaro.org> When running 4.13-rc1 on top of D05, I got the boot log: [0.00] SRAT: PXM 0 -> ITS 0 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 1 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 2 -> Node 0 [0.00] SRAT: PXM 1 -> IT

[PATCH v2] irqchip/gic-v3-its: Allow GIC ITS number more than MAX_NUMNODES

From: Hanjun Guo When running 4.13-rc1 on top of D05, I got the boot log: [0.00] SRAT: PXM 0 -> ITS 0 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 1 -> Node 0 [0.00] SRAT: PXM 0 -> ITS 2 -> Node 0 [0.00] SRAT: PXM 1 -> ITS 3 -> Node 1 [0.00

<    1   2   3   4   5   6   7   8   9   10   >