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

2018-10-18 Thread Hanjun Guo
On 2018/10/18 19:56, Marc Zyngier wrote: > Hi Hanjun, > > On 18/10/18 12:20, Hanjun Guo wrote: >> Hi Marc, >> >>>>>> >>>>> Now, the biggest question of them all: how does it work with ACPI? Last >>>>> time I checke

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

2018-10-18 Thread Hanjun Guo
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

2018-06-22 Thread Hanjun Guo
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

2018-06-14 Thread Hanjun Guo
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

2018-06-07 Thread Hanjun Guo
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

2018-06-07 Thread Hanjun Guo
.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

2018-05-31 Thread Hanjun Guo
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

2018-04-02 Thread Hanjun Guo
[+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

2018-04-02 Thread Hanjun Guo
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

2018-02-05 Thread Hanjun Guo
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 v3] ACPI / tables: Add IORT to injectable table list

2018-02-02 Thread Hanjun Guo
> 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 18/18] arm64: Kill PSCI_GET_VERSION as a variant-2 workaround

2018-02-01 Thread Hanjun Guo
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

2018-02-01 Thread Hanjun Guo
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

2018-01-31 Thread Hanjun Guo
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

2018-01-31 Thread Hanjun Guo
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

2018-01-31 Thread Hanjun Guo
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

2018-01-31 Thread Hanjun Guo
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()

2018-01-09 Thread Hanjun Guo
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: [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero

2018-01-06 Thread Hanjun Guo
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: [PATCH 05/23] x86, kaiser: unmap kernel from userspace page tables (core patch)

2018-01-06 Thread Hanjun Guo
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)

2018-01-05 Thread Hanjun Guo
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)

2018-01-05 Thread Hanjun Guo
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)

2018-01-05 Thread Hanjun Guo
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?

2018-01-01 Thread Hanjun Guo
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

2017-12-29 Thread Hanjun Guo
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 >

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

2017-12-28 Thread Hanjun Guo
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

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

2017-12-20 Thread Hanjun Guo
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: linux-next: Signed-off-by missing for commit in the rcu tree

2017-11-28 Thread Hanjun Guo
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: [PATCH v3 2/7] ACPI: Enable PPTT support on ARM64

2017-10-13 Thread Hanjun Guo
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 0/2] arm64 SMMUv3 PMU driver with IORT support

2017-10-12 Thread Hanjun Guo
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

2017-10-12 Thread Hanjun Guo
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

2017-10-10 Thread Hanjun Guo
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] tee: ACPI support for optee driver

2017-09-21 Thread Hanjun Guo
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

2017-09-05 Thread Hanjun Guo
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

2017-08-09 Thread Hanjun Guo
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

2017-08-09 Thread Hanjun Guo
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

2017-08-07 Thread Hanjun Guo
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 v4] acpi/iort: numa: Add numa node mapping for smmuv3 devices

2017-08-03 Thread Hanjun Guo
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

2017-08-03 Thread Hanjun Guo
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

2017-08-03 Thread Hanjun Guo
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 v2 5/5] ACPI/IORT: Add IORT named component memory address limits

2017-08-01 Thread Hanjun Guo
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

2017-08-01 Thread Hanjun Guo
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

2017-07-27 Thread Hanjun Guo
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

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

2017-07-26 Thread Hanjun Guo
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:

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

2017-07-26 Thread Hanjun Guo
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

2017-07-26 Thread Hanjun Guo
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

2017-07-26 Thread Hanjun Guo
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

2017-07-26 Thread Hanjun Guo
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

2017-07-26 Thread Hanjun Guo
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

2017-07-26 Thread Hanjun Guo
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

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

2017-07-21 Thread Hanjun Guo
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

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

2017-07-21 Thread Hanjun Guo
On 2017/7/21 19:42, Ganapatrao Kulkarni wrote: > Hi Hanjun, > > > On Fri, Jul 21, 2017 at 4:50 PM, Marc Zyngier <marc.zyng...@arm.com> wrote: >> On 21/07/17 11:06, Hanjun Guo wrote: >>> On 2017/7/21 17:51, Hanjun Guo wrote: >>>> From: Hanjun Guo <ha

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

2017-07-21 Thread Hanjun Guo
On 2017/7/21 19:20, Marc Zyngier wrote: > On 21/07/17 11:06, Hanjun Guo wrote: >> On 2017/7/21 17:51, Hanjun Guo wrote: >>> From: Hanjun Guo <hanjun@linaro.org> >>> >>> When running 4.13-rc1 on top of D05, I got the boot log: >>>

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

2017-07-21 Thread Hanjun Guo
Hi Ganapat, On 2017/6/8 12:44, Ganapatrao Kulkarni wrote: > Add code to parse proximity domain in SMMUv3 IORT table to > set numa node mapping for smmuv3 devices. > > Signed-off-by: Ganapatrao Kulkarni > --- > drivers/acpi/arm64/iort.c | 28

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

2017-07-21 Thread Hanjun Guo
On 21 July 2017 at 18:06, Hanjun Guo <guohan...@huawei.com> wrote: > > On 2017/7/21 17:51, 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:

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

2017-07-21 Thread Hanjun Guo
On 2017/7/21 17:51, 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

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

2017-07-21 Thread Hanjun Guo
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

Re: [PATCH v2 2/5] ACPI / boot: Correct address space of __acpi_map_table()

2017-07-18 Thread Hanjun Guo
On 2017/7/18 17:23, Andy Shevchenko wrote: > On Tue, 2017-07-18 at 11:03 +0200, Geert Uytterhoeven wrote: >> Hi Andy, >> >> On Mon, Jul 17, 2017 at 12:24 PM, Andy Shevchenko >> wrote: >>> Sparse complains about wrong address space used in >>> __acpi_map_table()

Re: [PATCH v2 5/5] ACPI / boot: Don't handle SCI on HW reduced platforms

2017-07-18 Thread Hanjun Guo
On 2017/7/17 21:29, Andy Shevchenko wrote: > WIP Does it mean not ready for upstream yet? Thanks Hanjun

Re: [PATCH v2 2/5] ACPI / boot: Correct address space of __acpi_map_table()

2017-07-18 Thread Hanjun Guo
-- a/include/linux/acpi.h > +++ b/include/linux/acpi.h > @@ -228,8 +228,8 @@ struct acpi_subtable_proc { > int count; > }; > > -char * __acpi_map_table (unsigned long phys_addr, unsigned long size); > -void __acpi_unmap_table(char *map, unsigned long size); > +void __iomem *__acp

Re: [PATCH v1 1/2] ACPI / boot: Correct address space of __acpi_map_table()

2017-07-17 Thread Hanjun Guo
On 2017/7/8 23:50, Andy Shevchenko wrote: > Sparse complains about wrong address space used in __acpi_map_table() > and in __acpi_unmap_table(). > > arch/x86/kernel/acpi/boot.c:127:29: warning: incorrect type in return > expression (different address spaces) > arch/x86/kernel/acpi/boot.c:127:29:

Re: [PATCH RESEND] arm64: arch_timer: fix the infinite recursion when enable ftrace and erratum workaround

2017-07-10 Thread Hanjun Guo
eg);\ > } \ This fixes my system hang issue when I using function tracer with enabled timer errata on D03, Tested-by: Hanjun Guo <hanjun@linaro.org> Thanks Hanjun

Re: [PATCH] irqdomain: Allow ACPI device nodes to be used as irqdomain identifiers

2017-07-07 Thread Hanjun Guo
On 2017/7/7 16:39, Marc Zyngier wrote: > A number of irqchip implementations are (ab)using the irqdomain > allocator by passing a fwnode that is neither a FWNODE_OF or > a FWNODE_IRQCHIP. > > This is pretty bad, but it also feels pretty crap to force these > drivers to allocate their own

Re: [PATCH 1/2] genirq: Get the fwnode back for irqchips being probed via ACPI namespace

2017-07-07 Thread Hanjun Guo
On 2017/7/7 16:17, Marc Zyngier wrote: > On 07/07/17 04:27, Hanjun Guo wrote: >> On 2017/7/6 21:05, Marc Zyngier wrote: >>> On 06/07/17 10:01, Hanjun Guo wrote: >>>> Hi Marc, >>>> >>>> On 2017/7/6 15:43, Marc Zyngier wrote: >>>>>

Re: [PATCH 1/2] genirq: Get the fwnode back for irqchips being probed via ACPI namespace

2017-07-06 Thread Hanjun Guo
On 2017/7/6 21:05, Marc Zyngier wrote: > On 06/07/17 10:01, Hanjun Guo wrote: >> Hi Marc, >> >> On 2017/7/6 15:43, Marc Zyngier wrote: >>> On 06/07/17 05:35, Hanjun Guo wrote: >>>> From: Hanjun Guo <hanjun@linaro.org> >>>>

Re: [PATCH 2/2] genirq: Use is_fwnode_irqchip() directly

2017-07-06 Thread Hanjun Guo
Hi Ethan, On 2017/7/6 13:46, Ethan Zhao wrote: > Hanjun, > > What branch is this patch for ? Check v4.12, failed to apply. I prepared patches based on master branch of linux-next git tree, but they can be applied cleanly on top of latest Linus tree. This patch set is for latest merged 4.13

[PATCH 2/2] genirq: Use is_fwnode_irqchip() directly

2017-07-05 Thread Hanjun Guo
From: Hanjun Guo <hanjun@linaro.org> is_fwnode_irqchip() already check fwnode is NULL or not, just use is_fwnode_irqchip() directly. Signed-off-by: Hanjun Guo <hanjun@linaro.org> --- kernel/irq/irqdomain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 1/2] genirq: Get the fwnode back for irqchips being probed via ACPI namespace

2017-07-05 Thread Hanjun Guo
From: Hanjun Guo <hanjun@linaro.org> commit d59f6617eef0 (genirq: Allow fwnode to carry name information only) forgot to do "domain->fwnode = fwnode;" for irqchips being probed via ACPI namesapce (DSDT/SSDT), that will break platforms with irqchip such as mbigen or qco

[PATCH] char: ipmi: eliminate misleading print info when being probed via ACPI

2017-07-03 Thread Hanjun Guo
From: Hanjun Guo <hanjun@linaro.org> When ipmi is probed via ACPI, the boot log shows [ 17.945139] ipmi_si IPI0001:00: probing via device tree [ 17.950369] ipmi_si IPI0001:00: ipmi_si: probing via ACPI [ 17.955795] ipmi_si IPI0001:00: [io 0x00e4-0x3fff] regsize 1 spacing 1

Re: [v6 2/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #74

2017-06-06 Thread Hanjun Guo
On 2017/5/17 18:13, Shameerali Kolothum Thodi wrote: #ifdef CONFIG_ACPI +static void acpi_smmu_get_options(u32 model, struct arm_smmu_device +*smmu) { + if (model == ACPI_IORT_SMMU_CAVIUM_CN99XX) + smmu->options |= ARM_SMMU_OPT_PAGE0_REGS_ONLY; > HiSIlicon hip06/07 boards

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

2017-06-01 Thread Hanjun Guo
[+Cc Lv Zheng] On 2017/6/2 0:21, Lorenzo Pieralisi wrote: > On Thu, Jun 01, 2017 at 07:35:37PM +0530, Ganapatrao Kulkarni wrote: >> ARM IORT specification has provision to define Proximity domain >> in SMMUv3 IORT table. Adding required code to parse Proximity domain of >> SMMUv3 IORT table.

[tip:irq/urgent] irqchip/mbigen: Fix potential NULL dereferencing

2017-05-12 Thread tip-bot for Hanjun Guo
Commit-ID: ad7cc3c0c57d77b442db323056354d0e49833569 Gitweb: http://git.kernel.org/tip/ad7cc3c0c57d77b442db323056354d0e49833569 Author: Hanjun Guo <hanjun@linaro.org> AuthorDate: Fri, 12 May 2017 11:55:27 +0800 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate:

[tip:irq/urgent] irqchip/mbigen: Fix memory mapping code

2017-05-12 Thread tip-bot for Hanjun Guo
Commit-ID: 5ba9b0a14132d0b8d97affe909f324045a968d03 Gitweb: http://git.kernel.org/tip/5ba9b0a14132d0b8d97affe909f324045a968d03 Author: Hanjun Guo <hanjun@linaro.org> AuthorDate: Fri, 12 May 2017 11:55:26 +0800 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate:

[PATCH v2 2/3] irqchip/mbigen: Fix potential NULL dereferencing

2017-05-11 Thread Hanjun Guo
From: Hanjun Guo <hanjun@linaro.org> platform_get_resource() may return NULL, add proper check to avoid potential NULL dereferencing. Signed-off-by: Hanjun Guo <hanjun@linaro.org> --- drivers/irqchip/irq-mbigen.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers

[PATCH v2 3/3] irqchip/mbigen: Fix the clear register offset

2017-05-11 Thread Hanjun Guo
7b8820 ("irqchip/mbigen: Implement the mbigen irq chip operation functions") Signed-off-by: MaJun <majun...@huawei.com> Signed-off-by: Hanjun Guo <hanjun@linaro.org> --- drivers/irqchip/irq-mbigen.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/dr

[PATCH v2 1/3] irqchip/mbigen: Fix memory mapping code

2017-05-11 Thread Hanjun Guo
From: Hanjun Guo <hanjun@linaro.org> Some mbigens share memory regions, and devm_ioremap_resource does not allow to share resources which will break the probe of mbigen, in opposition to devm_ioremap. This patch restores back usage of devm_ioremap function, but with proper error ha

[PATCH v2 0/3] irqchip/mbigen: bugfixs

2017-05-11 Thread Hanjun Guo
From: Hanjun Guo <hanjun@linaro.org> Here are 3 bugfixes for mbigen: Patch 1 is a critical bugfix which to fix the mbigen probe failure, commit 216646e4d82e ("irqchip/mbigen: Fix return value check in mbigen_device_probe()") introduced this breakage; Patch 2 fixes

Re: [PATCH v3 3/7] ACPICA: IORT: Add Cavium ThunderX2 SMMUv3 model definition.

2017-05-05 Thread Hanjun Guo
On 2017/5/5 20:08, Geetha sowjanya wrote: From: Linu Cherian Add SMMUv3 model definition for ThunderX2. Signed-off-by: Linu Cherian Signed-off-by: Geetha Sowjanya --- include/acpi/actbl2.h | 2 ++ 1 file

[PATCH 2/3] irqchip/mbigen: Fix potential NULL dereferencing

2017-05-02 Thread Hanjun Guo
From: Hanjun Guo <hanjun@linaro.org> platform_get_resource() may return NULL, add proper check to avoid potential NULL dereferencing. Signed-off-by: Hanjun Guo <hanjun@linaro.org> --- drivers/irqchip/irq-mbigen.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers

[PATCH 1/3] irqchip/mbigen: Fix memory mapping code

2017-05-02 Thread Hanjun Guo
From: Hanjun Guo <hanjun@linaro.org> Some mbigens share memory regions, and devm_ioremap_resource does not allow to share resources which will break the probe of mbigen, in opposition to devm_ioremap. This patch restores back usage of devm_ioremap function, but with proper error ha

[PATCH 3/3] irqchip/mbigen: Fix the clear register offset

2017-05-02 Thread Hanjun Guo
7b8820 ("irqchip/mbigen: Implement the mbigen irq chip operation functions") Signed-off-by: MaJun <majun...@huawei.com> Signed-off-by: Hanjun Guo <hanjun@linaro.org> --- drivers/irqchip/irq-mbigen.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/dr

Re: [PATCH] irqchip/mbigen: Fix the clear register offset

2017-04-26 Thread Hanjun Guo
On 2017/4/27 9:27, majun (Euler7) wrote: Hi Marc: 在 2017/4/26 16:01, Marc Zyngier 写道: On 26/04/17 04:10, Hanjun Guo wrote: Hi Majun, On 2017/4/25 10:16, Majun wrote: From: MaJun <majun...@huawei.com> Don't minus reserved interrupts (64) when get the clear register offset,because the

Re: [PATCH] irqchip/mbigen: Fix the clear register offset

2017-04-25 Thread Hanjun Guo
Hi Majun, On 2017/4/25 10:16, Majun wrote: From: MaJun Don't minus reserved interrupts (64) when get the clear register offset,because the clear register space includes the space of these 64 interrupts. Could you mention the background that there is a timeout mechanism

Re: [PATCH v3 15/18] arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround is enabled

2017-04-24 Thread Hanjun Guo
t; probe for the counter frequency, leading to an UNDEF exception > as CNTVCT_EL0 and CNTFRQ_EL0 share the same control bit. > > The fix is to handle the exception the same way we do for CNTVCT_EL0. > > Fixes: a86bd139f2ae ("arm64: arch_timer: Enable CNTVCT_EL0 trap if workaround

Re: [PATCH v8 10/15] ACPI: platform-msi: retrieve dev id from IORT

2017-04-17 Thread Hanjun Guo
On 2017/4/18 9:30, Sinan Kaya wrote: > On 4/17/2017 9:27 PM, Hanjun Guo wrote: >> Patches were merged via two trees: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=irq/core >> https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?

Re: [PATCH v8 10/15] ACPI: platform-msi: retrieve dev id from IORT

2017-04-17 Thread Hanjun Guo
Hi Sinan, On 2017/4/18 6:01, Sinan Kaya wrote: > On 4/17/2017 5:44 PM, Sinan Kaya wrote: >> Any idea what happened to the change in this function during merge? >> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ae7c18380495ac5c14a614fdb6c452c3bf9148ac >> > I

Re: [PATCH v2] ACPI : Update platform device numa node based on _PXM method

2017-04-12 Thread Hanjun Guo
kfree(resources); + return pdev; } EXPORT_SYMBOL_GPL(acpi_create_platform_device); Reviewed-by: Hanjun Guo <hanjun@linaro.org> Thanks Hanjun

Re: [PATCH v9 10/15] ACPI: platform-msi: retrieve dev id from IORT

2017-03-29 Thread Hanjun Guo
On 03/30/2017 01:32 AM, Lorenzo Pieralisi wrote: On Wed, Mar 29, 2017 at 05:13:54PM +0100, Lorenzo Pieralisi wrote: On Wed, Mar 29, 2017 at 03:52:47PM +0100, Marc Zyngier wrote: On 29/03/17 14:00, Hanjun Guo wrote: On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote: On Wed, Mar 29, 2017 at 07

Re: [PATCH v9 10/15] ACPI: platform-msi: retrieve dev id from IORT

2017-03-29 Thread Hanjun Guo
On 03/29/2017 08:38 PM, Lorenzo Pieralisi wrote: On Wed, Mar 29, 2017 at 07:52:48PM +0800, Hanjun Guo wrote: Hi Lorenzo, On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote: Hi Hanjun, Marc, On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote: From: Hanjun Guo <hanjun@linaro.

Re: [PATCH v9 10/15] ACPI: platform-msi: retrieve dev id from IORT

2017-03-29 Thread Hanjun Guo
Hi Lorenzo, On 03/29/2017 06:14 PM, Lorenzo Pieralisi wrote: Hi Hanjun, Marc, On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote: From: Hanjun Guo <hanjun@linaro.org> For devices connecting to ITS, the devices need to identify themself through a dev id; this dev id is repre

Re: [Update][PATCH v9.1 15/15] irqchip: mbigen: Add ACPI support

2017-03-28 Thread Hanjun Guo
On 03/29/2017 03:13 AM, Al Stone wrote: On 03/28/2017 06:21 AM, Hanjun Guo wrote: [...] +#ifdef CONFIG_ACPI +static int mbigen_acpi_create_domain(struct platform_device *pdev, +struct mbigen_device *mgn_chip) +{ + struct irq_domain *domain

[Update][PATCH v9.1 15/15] irqchip: mbigen: Add ACPI support

2017-03-28 Thread Hanjun Guo
., "\_SB.MBI0") {12, ...} }) } So for the devices connected to the mbigen, as we clearly say that it refers to a specific interrupt controller (mbigen), we can get the virq from mbigen's irqdomain once it's created successfully. Signed-off-by: Hanjun Guo <hanju

Re: [PATCH v9 15/15] irqchip: mbigen: Add ACPI support

2017-03-27 Thread Hanjun Guo
Hanjun, John, On 22/03/17 14:12, John Garry wrote: On 21/03/2017 14:45, Lorenzo Pieralisi wrote: On Tue, Mar 07, 2017 at 08:40:10PM +0800, Hanjun Guo wrote: From: Hanjun Guo <hanjun@linaro.org> With the preparation of platform msi support and interrupt producer in DSDT, we can add mbige

Re: [PATCH v9 10/15] ACPI: platform-msi: retrieve dev id from IORT

2017-03-11 Thread Hanjun Guo
On 2017/3/7 22:35, Lorenzo Pieralisi wrote: > On Tue, Mar 07, 2017 at 08:40:05PM +0800, Hanjun Guo wrote: >> From: Hanjun Guo <hanjun@linaro.org> >> >> For devices connecting to ITS, the devices need to identify themself >> through a dev id; this dev id

Re: [PATCH v9 00/15] ACPI platform MSI support and its example mbigen

2017-03-09 Thread Hanjun Guo
Hi Marc, On 2017/3/7 22:43, Lorenzo Pieralisi wrote: On Tue, Mar 07, 2017 at 08:39:55PM +0800, Hanjun Guo wrote: From: Hanjun Guo <hanjun@linaro.org> With platform msi support landed in the kernel, and the introduction of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for pl

Re: [PATCH 01/17] arm64: arch_timer: Add infrastructure for multiple erratum detection methods

2017-03-07 Thread Hanjun Guo
globally applicable workarounds */ + arch_timer_check_ool_workaround(ate_match_dt, np); /* * If we cannot rely on firmware initializing the timer registers then It's cool to me, Reviewed-by: Hanjun Guo <hanjun@linaro.org> Thanks Hanjun

Re: [PATCH 00/17] clocksource/arch_timer: Errara workaround infrastructure rework

2017-03-07 Thread Hanjun Guo
[0.00] arm_arch_timer: CPU0: Trapping CNTVCT access [0.00] arm_arch_timer: Architected cp15 timer(s) running at 50.00MHz (phys). With patches other than Cortex-A73 erratum, Tested-by: Hanjun Guo <hanjun@linaro.org> Thanks Hanjun

Re: [PATCH 07/17] arm64: arch_timer: Rework the set_next_event workarounds

2017-03-07 Thread Hanjun Guo
On 2017/3/6 19:26, Marc Zyngier wrote: The way we work around errata affecting set_next_event is not very nice, at it imposes this workaround on errata that do not need it. Add new workaround hooks and let the existing workarounds use them. Signed-off-by: Marc Zyngier

Re: [PATCH 17/17] arm64: arch_timer: Add HISILICON_ERRATUM_161010101 ACPI matching data

2017-03-07 Thread Hanjun Guo
read_cntvct_el0 = hisi_161010101_read_cntvct_el0, + .set_next_event_phys = erratum_set_next_event_tval_phys, + .set_next_event_virt = erratum_set_next_event_tval_virt, + }, #endif #ifdef CONFIG_ARM64_ERRATUM_858921 { Reviewed-by: Hanjun Guo <hanjun@linaro.org> Thanks Hanjun

Re: [PATCH 16/17] arm64: arch_timer: Allow erratum matching with ACPI OEM information

2017-03-07 Thread Hanjun Guo
rch_timer_init(); return 0; Reviewed-by: Hanjun Guo <hanjun@linaro.org> Thanks Hanjun

  1   2   3   4   5   6   7   8   9   10   >