Re: [PATCH v5 3/5] iommu/io-pgtable-arm: add support for non-strict mode

2018-08-27 Thread Leizhen (ThunderTown)
On 2018/8/23 1:52, Robin Murphy wrote: > On 15/08/18 02:28, Zhen Lei wrote: >> To support the non-strict mode, now we only tlbi and sync for the strict >> mode. But for the non-leaf case, always follow strict mode. >> >> Signed-off-by: Zhen Lei >> --- >> drivers/iommu/io-pgtable-arm.c | 20

Re: [PATCH 1/1] iommu/arm-smmu-v3: eliminate a potential memory corruption on Hi16xx soc

2018-10-16 Thread Leizhen (ThunderTown)
On 2018/10/15 19:17, John Garry wrote: > On 15/10/2018 09:36, Zhen Lei wrote: >> ITS translation register map: >> 0x-0x003CReserved >> 0x0040GITS_TRANSLATER >> 0x0044-0xFFFCReserved >> > > Can you add a better opening than the ITS translation register map? OK > >> The

Re: [PATCH 1/1] iommu/arm-smmu-v3: eliminate a potential memory corruption on Hi16xx soc

2018-10-16 Thread Leizhen (ThunderTown)
On 2018/10/15 20:46, Andrew Murray wrote: > Hi Zhen, > > On Mon, Oct 15, 2018 at 04:36:16PM +0800, Zhen Lei wrote: >> ITS translation register map: >> 0x-0x003CReserved >> 0x0040 GITS_TRANSLATER >> 0x0044-0xFFFCReserved >> >> The standard GITS_TRANSLATER

Re: [PATCH 0/5] iommu/arm-smmu-v3: make smmu can be enabled in kdump kernel

2019-02-26 Thread Leizhen (ThunderTown)
Hi Will, Robin: Do you have time to review these patches? Hope you can give me some opinions. On 2019/2/19 15:54, Zhen Lei wrote: > This patch series include two parts: > 1. Patch1-2 use dummy STE tables with "ste abort" hardware feature to abort > unexpected >devices accessing. For more

Re: [PATCH RFC 1/1] iommu: set the default iommu-dma mode as non-strict

2019-02-28 Thread Leizhen (ThunderTown)
On 2019/2/26 20:36, Hanjun Guo wrote: > Hi Jean, > > On 2019/1/31 22:55, Jean-Philippe Brucker wrote: >> Hi, >> >> On 31/01/2019 13:52, Zhen Lei wrote: >>> Currently, many peripherals are faster than before. For example, the top >>> speed of the older netcard is 10Gb/s, and now it's more than

Re: [PATCH 2/5] iommu/arm-smmu-v3: make smmu can be enabled in kdump kernel

2019-03-01 Thread Leizhen (ThunderTown)
It seems that the picture is too big, I change it from jpg to png. On 2019/3/1 17:02, Leizhen (ThunderTown) wrote: > Hi All, > I drew a flowchart, hope this can help you to understand my method. > > On 2019/2/19 15:54, Zhen Lei wrote: >> To reduce the ris

Re: [PATCH RFC 1/1] iommu: set the default iommu-dma mode as non-strict

2019-03-01 Thread Leizhen (ThunderTown)
On 2019/3/1 19:07, Jean-Philippe Brucker wrote: > Hi Leizhen, > > On 01/03/2019 04:44, Leizhen (ThunderTown) wrote: >> >> >> On 2019/2/26 20:36, Hanjun Guo wrote: >>> Hi Jean, >>> >>> On 2019/1/31 22:55, Jean-Philippe Brucker wrote:

Re: [PATCH RFC 1/1] iommu: set the default iommu-dma mode as non-strict

2019-03-06 Thread Leizhen (ThunderTown)
On 2019/3/4 23:52, Robin Murphy wrote: > On 02/03/2019 06:12, Leizhen (ThunderTown) wrote: >> >> >> On 2019/3/1 19:07, Jean-Philippe Brucker wrote: >>> Hi Leizhen, >>> >>> On 01/03/2019 04:44, Leizhen (ThunderTown) wrote: >>>> &

Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?

2018-06-06 Thread Leizhen (ThunderTown)
On 2018/6/7 1:48, h...@zytor.com wrote: > On June 6, 2018 2:17:42 AM PDT, "Leizhen (ThunderTown)" > wrote: >> I found that glibc has already dealt with this case. So this issue must >> have been met before, should it be maintained by libc/user? >> >&g

Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?

2018-06-06 Thread Leizhen (ThunderTown)
On 2018/6/7 1:01, Andy Lutomirski wrote: > On Wed, Jun 6, 2018 at 2:18 AM Leizhen (ThunderTown) > wrote: >> >> I found that glibc has already dealt with this case. So this issue must have >> been met before, should it be maintained by libc/user? >> >>

Re: Is this a kernel BUG? ///Re: [Question] Can we use SIGRTMIN when vdso disabled on X86?

2018-06-06 Thread Leizhen (ThunderTown)
On 2018/6/7 10:39, Andy Lutomirski wrote: > > >> On Jun 6, 2018, at 7:05 PM, Leizhen (ThunderTown) >> wrote: >> >> >> >>> On 2018/6/7 1:01, Andy Lutomirski wrote: >>> On Wed, Jun 6, 2018 at 2:18 AM Leizhen (ThunderTown) >

[Question] Are the trace APIs declared by "TRACE_EVENT(irq_handler_entry" allowed to be used in Ko?

2018-09-11 Thread Leizhen (ThunderTown)
After patch 7e066fb870fc ("tracepoints: add DECLARE_TRACE() and DEFINE_TRACE()"), the trace APIs declared by "TRACE_EVENT(irq_handler_entry" can not be directly used by ko, because it's not explicitly exported by EXPORT_TRACEPOINT_SYMBOL_GPL or EXPORT_TRACEPOINT_SYMBOL. Did we miss it? or it's

Re: [PATCH v2 0/1] of: to support binding numa node to specified device

2015-09-10 Thread Leizhen (ThunderTown)
Sorry, missed version number in title. On 2015/8/25 12:08, Zhen Lei wrote: > Changelog: > v1 -> v2: > In patch v1, binding numa node to specified device only take effect for > dt-nodes > directly of root. Patch v2 removed this limitation, we can binding numa node > to > any specified device in

Re: [PATCH v2 1/1] of: to support binding numa node to specified device in devicetree

2015-09-10 Thread Leizhen (ThunderTown)
Hi all, Can somebody take a few moments to review it? This patch is too small, only changed two lines. Thanks, Thunder. On 2015/8/25 12:08, Zhen Lei wrote: > For now, in function device_add, the new device will be forced to > inherit the numa node of its parent. But this will override the

Re: [PATCH 1/1] of: to support binding numa node to root subnode(non-bus)

2015-08-24 Thread Leizhen (ThunderTown)
On 2015/8/24 21:25, Rob Herring wrote: > +benh > > On Mon, Aug 24, 2015 at 7:30 AM, Zhen Lei wrote: >> If use of_platform_populate to scan dt-nodes and add devices, the >> subnode of root(such as /smmu), when being scanned and invoke > > You should have a bus as the sub-node of root rather

Re: [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc

2016-10-25 Thread Leizhen (ThunderTown)
On 2016/10/25 21:23, Michal Hocko wrote: > On Tue 25-10-16 10:59:17, Zhen Lei wrote: >> If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are >> actually exist. The percpu variable areas and numa control blocks of that >> memoryless numa nodes need to be allocated from the

Re: [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc

2016-10-26 Thread Leizhen (ThunderTown)
On 2016/10/26 17:31, Michal Hocko wrote: > On Wed 26-10-16 11:10:44, Leizhen (ThunderTown) wrote: >> >> >> On 2016/10/25 21:23, Michal Hocko wrote: >>> On Tue 25-10-16 10:59:17, Zhen Lei wrote: >>>> If HAVE_MEMORYLESS_NODES is selected, and some mem

Re: [PATCH 2/2] arm64/numa: support HAVE_MEMORYLESS_NODES

2016-10-26 Thread Leizhen (ThunderTown)
On 2016/10/27 2:36, Will Deacon wrote: > On Tue, Oct 25, 2016 at 10:59:18AM +0800, Zhen Lei wrote: >> Some numa nodes may have no memory. For example: >> 1) a node has no memory bank plugged. >> 2) a node has no memory bank slots. >> >> To ensure percpu variable areas and numa control blocks of

Re: [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc

2016-10-27 Thread Leizhen (ThunderTown)
On 2016/10/27 15:22, Michal Hocko wrote: > On Thu 27-10-16 10:41:24, Leizhen (ThunderTown) wrote: >> >> >> On 2016/10/26 17:31, Michal Hocko wrote: >>> On Wed 26-10-16 11:10:44, Leizhen (ThunderTown) wrote: >>>> >>>> >>>> On 20

Re: [PATCH 1/2] of, numa: Add function to disable of_node_to_nid().

2016-10-27 Thread Leizhen (ThunderTown)
On 2016/10/27 1:00, David Daney wrote: > On 10/26/2016 06:43 AM, Robert Richter wrote: >> On 25.10.16 14:31:00, David Daney wrote: >>> From: David Daney >>> >>> On arm64 NUMA kernels we can pass "numa=off" on the command line to >>> disable NUMA. A side effect of this is that kmalloc_node()

Re: [PATCH v7 11/14] arm64/numa: support HAVE_MEMORYLESS_NODES

2016-08-28 Thread Leizhen (ThunderTown)
On 2016/8/27 19:05, Leizhen (ThunderTown) wrote: > > > On 2016/8/26 23:43, Will Deacon wrote: >> On Wed, Aug 24, 2016 at 03:44:50PM +0800, Zhen Lei wrote: >>> Some numa nodes may have no memory. For example: >>> 1. cpu0 on node0 >>> 2. cpu1 on node1 &

Re: [PATCH v7 12/14] arm64/numa: remove the limitation that cpu0 must bind to node0

2016-08-29 Thread Leizhen (ThunderTown)
On 2016/8/26 23:49, Will Deacon wrote: > On Wed, Aug 24, 2016 at 03:44:51PM +0800, Zhen Lei wrote: >> 1. Currently only cpu0 set on cpu_possible_mask and percpu areas have not >>been initialized. This description refer to below: - for_each_possible_cpu(cpu) -

Re: [PATCH v7 05/14] arm64/numa: avoid inconsistent information to be printed

2016-08-30 Thread Leizhen (ThunderTown)
On 2016/8/31 1:51, Will Deacon wrote: > On Sat, Aug 27, 2016 at 04:54:56PM +0800, Leizhen (ThunderTown) wrote: >> >> >> On 2016/8/26 20:47, Will Deacon wrote: >>> On Wed, Aug 24, 2016 at 03:44:44PM +0800, Zhen Lei wrote: >>>> numa_init(of_num

Re: [PATCH v7 14/14] Documentation: remove the constraint on the distances of node pairs

2016-08-30 Thread Leizhen (ThunderTown)
On 2016/8/31 1:55, Will Deacon wrote: > On Sat, Aug 27, 2016 at 06:44:39PM +0800, Leizhen (ThunderTown) wrote: >> >> >> On 2016/8/26 23:35, Will Deacon wrote: >>> On Wed, Aug 24, 2016 at 03:44:53PM +0800, Zhen Lei wrote: >>>> Update documentation. This l

Re: [PATCH 1/7] iommu/iova: fix incorrect variable types

2017-03-23 Thread Leizhen (ThunderTown)
On 2017/3/23 19:42, Robin Murphy wrote: > On 22/03/17 06:27, Zhen Lei wrote: >> Keep these four variables type consistent with the paramters of function >> __alloc_and_insert_iova_range and the members of struct iova: >> >> 1. static int __alloc_and_insert_iova_range(struct iova_domain *iovad,

Re: [PATCH 3/7] iommu/iova: insert start_pfn boundary of dma32

2017-03-23 Thread Leizhen (ThunderTown)
On 2017/3/23 21:01, Robin Murphy wrote: > On 22/03/17 06:27, Zhen Lei wrote: >> Reserve the first granule size memory(start at start_pfn) as boundary >> iova, to make sure that iovad->cached32_node can not be NULL in future. >> Meanwhile, changed the assignment of iovad->cached32_node from

Re: aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must bind to node0")

2016-10-17 Thread Leizhen (ThunderTown)
>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c >> index d3f151cfd4a1..8507703dabe4 100644 >> --- a/arch/arm64/kernel/smp.c >> +++ b/arch/arm64/kernel/smp.c >> @@ -544,6 +544,7 @@ acpi_map_gic_cpu_interface(struct >> acpi_madt_generic_interrupt *processor) >>

Re: [PATCH v8 00/16] fix some type infos and bugs for arm64/of numa

2016-09-08 Thread Leizhen (ThunderTown)
On 2016/9/8 19:01, Will Deacon wrote: > On Thu, Sep 01, 2016 at 02:54:51PM +0800, Zhen Lei wrote: >> v7 -> v8: >> Updated patches according to Will Deacon's review comments, thanks. >> >> The changed patches is: 3, 5, 8, 9, 10, 11, 12, 13, 15 >> Patch 3 requires an ack from Rob Herring. >> Patch

Re: [PATCH v8 10/16] mm/memblock: add a new function memblock_alloc_near_nid

2016-09-08 Thread Leizhen (ThunderTown)
Hi, linux-mm folks: Can somebody help me to review this patch? I ran scripts/get_maintainer.pl -f mm/memblock.c and scripts/get_maintainer.pl -f mm/, but the results showed me that there is no maintainer. To understand this patch should also read patch 11. On 2016/9/1 14:55, Zhen Lei

Re: [RFC] Arm64 boot fail with numa enable in BIOS

2016-09-19 Thread Leizhen (ThunderTown)
On 2016/9/19 22:45, Will Deacon wrote: > On Mon, Sep 19, 2016 at 03:07:19PM +0100, Mark Rutland wrote: >> [adding LAKML, arm64 maintainers] > > I've also looped in Euler ThunderTown, since (a) he's at Huawei and is > assumedly testing this stuff and (b) he has a fairly big NUMA patch > series

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

2016-08-24 Thread Leizhen (ThunderTown)
On 2016/8/24 18:30, Catalin Marinas wrote: > On Wed, Aug 24, 2016 at 05:00:50PM +0800, Leizhen (ThunderTown) wrote: >> >> >> On 2016/8/24 1:28, Catalin Marinas wrote: >>> On Mon, Aug 22, 2016 at 12:19:04PM +0800, Leizhen (ThunderTown) wrote: >>>>

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

2016-08-25 Thread Leizhen (ThunderTown)
On 2016/8/25 17:30, Catalin Marinas wrote: > On Thu, Aug 25, 2016 at 09:42:26AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/8/24 18:30, Catalin Marinas wrote: >>>>>>>>>>>> On 2016/7/8 21:54, Catalin Marinas wrote: >>>>>>>>

Re: [PATCH v7 03/14] arm64/numa: add nid check for memory block

2016-08-27 Thread Leizhen (ThunderTown)
On 2016/8/26 20:39, Will Deacon wrote: > On Wed, Aug 24, 2016 at 03:44:42PM +0800, Zhen Lei wrote: >> Use the same tactic to cpu and numa-distance nodes. >> >> Signed-off-by: Zhen Lei >> --- >> drivers/of/of_numa.c | 5 + >> 1 file changed, 5 insertions(+) > > The subject has arm64/numa,

Re: [PATCH v7 05/14] arm64/numa: avoid inconsistent information to be printed

2016-08-27 Thread Leizhen (ThunderTown)
On 2016/8/26 20:47, Will Deacon wrote: > On Wed, Aug 24, 2016 at 03:44:44PM +0800, Zhen Lei wrote: >> numa_init(of_numa_init) may returned error because of numa configuration >> error. So "No NUMA configuration found" is inaccurate. In fact, specific >> configuration error information should be

Re: [PATCH v7 08/14] arm64: numa: Use pr_fmt()

2016-08-27 Thread Leizhen (ThunderTown)
On 2016/8/26 20:54, Will Deacon wrote: > On Wed, Aug 24, 2016 at 03:44:47PM +0800, Zhen Lei wrote: >> From: Kefeng Wang >> >> Use pr_fmt to prefix kernel output, and remove duplicated msg >> of NUMA turned off. >> >> Signed-off-by: Kefeng Wang >> --- >> arch/arm64/mm/numa.c | 40

Re: [PATCH v7 09/14] arm64/numa: support HAVE_SETUP_PER_CPU_AREA

2016-08-27 Thread Leizhen (ThunderTown)
On 2016/8/26 21:28, Will Deacon wrote: > On Wed, Aug 24, 2016 at 03:44:48PM +0800, Zhen Lei wrote: >> To make each percpu area allocated from its local numa node. Without this >> patch, all percpu areas will be allocated from the node which cpu0 belongs >> to. >> >> Signed-off-by: Zhen Lei >>

Re: [PATCH v7 10/14] arm64/numa: define numa_distance as array to simplify code

2016-08-27 Thread Leizhen (ThunderTown)
On 2016/8/26 23:29, Will Deacon wrote: > On Wed, Aug 24, 2016 at 03:44:49PM +0800, Zhen Lei wrote: >> 1. MAX_NUMNODES is base on CONFIG_NODES_SHIFT, the default value of the >>latter is very small now. >> 2. Suppose the default value of MAX_NUMNODES is enlarged to 64, so the >>size of

Re: [PATCH v7 14/14] Documentation: remove the constraint on the distances of node pairs

2016-08-27 Thread Leizhen (ThunderTown)
On 2016/8/26 23:35, Will Deacon wrote: > On Wed, Aug 24, 2016 at 03:44:53PM +0800, Zhen Lei wrote: >> Update documentation. This limit is unneccessary. >> >> Signed-off-by: Zhen Lei >> Acked-by: Rob Herring >> --- >> Documentation/devicetree/bindings/numa.txt | 1 - >> 1 file changed, 1

Re: [PATCH v7 11/14] arm64/numa: support HAVE_MEMORYLESS_NODES

2016-08-27 Thread Leizhen (ThunderTown)
On 2016/8/26 23:43, Will Deacon wrote: > On Wed, Aug 24, 2016 at 03:44:50PM +0800, Zhen Lei wrote: >> Some numa nodes may have no memory. For example: >> 1. cpu0 on node0 >> 2. cpu1 on node1 >> 3. device0 access the momory from node0 and node1 take the same time. >> >> So, we can not simply

Re: [PATCH 1/1] iommu/arm-smmu-v3: replace writel with writel_relaxed in queue_inc_prod

2017-06-20 Thread Leizhen (ThunderTown)
On 2017/6/20 19:35, Robin Murphy wrote: > On 20/06/17 12:04, Zhen Lei wrote: >> This function is protected by spinlock, and the latter will do memory >> barrier implicitly. So that we can safely use writel_relaxed. In fact, the >> dmb operation will lengthen the time protected by lock, which

Re: [Question or BUG] [NUMA]: I feel puzzled at the function cpumask_of_node

2017-06-14 Thread Leizhen (ThunderTown)
On 2017/6/8 22:12, Michal Hocko wrote: > [CC linux-api] > > On Wed 07-06-17 17:23:20, Leizhen (ThunderTown) wrote: >> When I executed numactl -H(print cpumask_of_node for each node), I got >> different result on X86 and ARM64. For each numa node, the former >>

[Question or BUG] [NUMA]: I feel puzzled at the function cpumask_of_node

2017-06-07 Thread Leizhen (ThunderTown)
When I executed numactl -H(print cpumask_of_node for each node), I got different result on X86 and ARM64. For each numa node, the former only displayed online CPUs, and the latter displayed all possible CPUs. Actually, all other ARCHs is the same to ARM64. So, my question is: Which case(online

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

2016-08-21 Thread Leizhen (ThunderTown)
On 2016/7/20 17:19, Catalin Marinas wrote: > On Wed, Jul 20, 2016 at 10:46:27AM +0800, Leizhen (ThunderTown) wrote: >>>>>> On 2016/7/8 21:54, Catalin Marinas wrote: >>>>>>> 8< >>>>>>> diff -

Re: [PATCH v6 00/14] fix some type infos and bugs for arm64/of numa

2016-08-22 Thread Leizhen (ThunderTown)
Hi everybody: Is this patch series can be accepted or still need to be improved? It seems to have been a long time. Thanks, Zhen Lei On 2016/8/11 17:33, Zhen Lei wrote: > v5 -> v6: > Move memblk nid check from arch/arm64/mm/numa.c into drivers/of/of_numa.c, > because this check is arch

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

2016-08-23 Thread Leizhen (ThunderTown)
On 2016/8/22 22:28, Catalin Marinas wrote: > On Sat, Aug 20, 2016 at 05:38:59PM +0800, zhong jiang wrote: >> On 2016/8/19 12:11, Ganapatrao Kulkarni wrote: >>> On Fri, Aug 19, 2016 at 9:30 AM, Ganapatrao Kulkarni >>> wrote: On Fri, Aug 19, 2016 at 7:28 AM, zhong jiang wrote: > On

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

2016-08-23 Thread Leizhen (ThunderTown)
On 2016/8/23 19:30, Will Deacon wrote: > On Tue, Aug 23, 2016 at 07:19:01PM +0800, Leizhen (ThunderTown) wrote: >> He applied my patches, which I mentioned these days. > > [...] > >> I will update my patch series and resend it again. > > To be clear, you p

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

2016-08-23 Thread Leizhen (ThunderTown)
On 2016/8/24 1:28, Catalin Marinas wrote: > On Mon, Aug 22, 2016 at 12:19:04PM +0800, Leizhen (ThunderTown) wrote: >> On 2016/7/20 17:19, Catalin Marinas wrote: >>> On Wed, Jul 20, 2016 at 10:46:27AM +0800, Leizhen (ThunderTown) wrote: >>>>>>>>

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

2016-08-24 Thread Leizhen (ThunderTown)
On 2016/8/24 1:28, Catalin Marinas wrote: > On Mon, Aug 22, 2016 at 12:19:04PM +0800, Leizhen (ThunderTown) wrote: >> On 2016/7/20 17:19, Catalin Marinas wrote: >>> On Wed, Jul 20, 2016 at 10:46:27AM +0800, Leizhen (ThunderTown) wrote: >>>>>>>>

Re: [PATCH v2] arm64: kernel: numa: fix ACPI boot cpu numa node mapping

2016-10-18 Thread Leizhen (ThunderTown)
On 2016/10/18 16:39, Hanjun Guo wrote: > On 2016/10/17 22:56, Lorenzo Pieralisi wrote: >> Commit 7ba5f605f3a0 ("arm64/numa: remove the limitation that cpu0 must >> bind to node0") removed the numa cpu<->node mapping restriction whereby >> logical cpu 0 always corresponds to numa node 0; removing

Re: [PATCH v8 10/16] mm/memblock: add a new function memblock_alloc_near_nid

2016-10-10 Thread Leizhen (ThunderTown)
On 2016/9/1 14:55, Zhen Lei wrote: > If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are > actually exist. The percpu variable areas and numa control blocks of that > memoryless numa nodes must be allocated from the nearest available node > to improve performance. > >

Re: [PATCH v8 10/16] mm/memblock: add a new function memblock_alloc_near_nid

2016-10-11 Thread Leizhen (ThunderTown)
On 2016/10/11 18:16, Will Deacon wrote: > On Tue, Oct 11, 2016 at 09:44:20AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/9/1 14:55, Zhen Lei wrote: >>> If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are >>> actually exist. The percpu vari

Re: [PATCH 1/7] iommu/iova: fix incorrect variable types

2017-03-30 Thread Leizhen (ThunderTown)
On 2017/3/24 10:27, Leizhen (ThunderTown) wrote: > > > On 2017/3/23 19:42, Robin Murphy wrote: >> On 22/03/17 06:27, Zhen Lei wrote: >>> Keep these four variables type consistent with the paramters of function >>> __alloc_and_insert_iova_range and the members

Re: [PATCH 3/7] iommu/iova: insert start_pfn boundary of dma32

2017-03-30 Thread Leizhen (ThunderTown)
Because the problem of my email-server, all patches sent to Joerg Roedel failed. So I repost this email again. On 2017/3/24 11:43, Leizhen (ThunderTown) wrote: > > > On 2017/3/23 21:01, Robin Murphy wrote: >> On 22/03/17 06:27, Zhen Lei wrote: >>> Reserve the first g

Re: [PATCH 2/7] iommu/iova: cut down judgement times

2017-03-30 Thread Leizhen (ThunderTown)
On 2017/3/23 20:11, Robin Murphy wrote: > On 22/03/17 06:27, Zhen Lei wrote: >> Below judgement can only be satisfied at the last time, which produced 2N >> judgements(suppose N times failed, 0 or 1 time successed) in vain. >> >> if ((pfn >= iova->pfn_lo) && (pfn <= iova->pfn_hi)) { >>

Re: [PATCH 1/1] tty/serial: to support 8250 earlycon can be enabled independently

2016-05-17 Thread Leizhen (ThunderTown)
On 2016/5/16 23:40, Peter Hurley wrote: > On 05/16/2016 04:35 AM, Zhen Lei wrote: >> Sometimes, we may only use SSH to login, and build 8250 uart driver as a >> ko(insmod if needed). But the earlycon may still be necessary, because >> the kernel boot process may take a long time. It's not good

Re: [PATCH 1/1] rtc: fix type information of rtc-proc

2015-11-10 Thread Leizhen (ThunderTown)
Hi, all I'm sorry. Maybe I didn't describe clearly enough before. These words are finally shown to the end user. The end user maybe not a programmer, abbreviation word is unsuitable. cat /proc/driver/rtc rtc_time: 00:47:43 rtc_date: 2015-11-11 alrm_time : 03:27:58

Re: [PATCH 1/1] rtc: fix type information of rtc-proc

2015-11-11 Thread Leizhen (ThunderTown)
On 2015/11/11 18:54, Alexandre Belloni wrote: > On 11/11/2015 at 09:06:51 +0800, Leizhen (ThunderTown) wrote : >> Hi, all >> >> I'm sorry. Maybe I didn't describe clearly enough before. These words are >> finally >> shown to the end user. The end user may

Re: [PATCH 2/2] arm64: to allow EFI_RTC can be selected on ARM64

2015-10-08 Thread Leizhen (ThunderTown)
On 2015/9/28 17:44, Leizhen (ThunderTown) wrote: >> > >>> >> --drivers/char/Kconfig-- >>> >> if RTC_LIB=n >>> >> >>> >> config RTC >>> >> tristate "Enhanced Real Time

Re: Suspicious error for CMA stress test

2016-03-08 Thread Leizhen (ThunderTown)
On 2016/3/8 9:54, Leizhen (ThunderTown) wrote: > > > On 2016/3/8 2:42, Laura Abbott wrote: >> On 03/07/2016 12:16 AM, Leizhen (ThunderTown) wrote: >>> >>> >>> On 2016/3/7 12:34, Joonsoo Kim wrote: >>>> On Fri, Mar 04, 2016 at 03:35:26PM +08

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

2016-07-19 Thread Leizhen (ThunderTown)
On 2016/7/12 23:35, Catalin Marinas wrote: > On Mon, Jul 11, 2016 at 08:43:32PM +0800, Leizhen (ThunderTown) wrote: >> On 2016/7/9 0:13, Catalin Marinas wrote: >>> On Fri, Jul 08, 2016 at 11:24:26PM +0800, Leizhen (ThunderTown) wrote: >>>> On 2016/7/

Re: [PATCH v5 03/14] arm64/numa: add nid check for memory block

2016-08-09 Thread Leizhen (ThunderTown)
On 2016/8/10 10:12, Hanjun Guo wrote: > On 2016/8/8 17:18, Zhen Lei wrote: >> Use the same tactic to cpu and numa-distance nodes. >> >> Signed-off-by: Zhen Lei >> --- >> arch/arm64/mm/numa.c | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/arch/arm64/mm/numa.c

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-21 Thread Leizhen (ThunderTown)
On 2016/6/20 14:39, Leizhen (ThunderTown) wrote: > > > On 2016/6/14 22:22, Catalin Marinas wrote: >> On Wed, Jun 08, 2016 at 04:59:03PM +0800, Leizhen (ThunderTown) wrote: >>> On 2016/6/7 21:58, Will Deacon wrote: >>>> On Tue, Jun 07, 2016 at 04:08:04PM +

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-20 Thread Leizhen (ThunderTown)
On 2016/6/14 22:22, Catalin Marinas wrote: > On Wed, Jun 08, 2016 at 04:59:03PM +0800, Leizhen (ThunderTown) wrote: >> On 2016/6/7 21:58, Will Deacon wrote: >>> On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote: >>>> v3 -> v4: >>>> 1. Packed t

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

2016-07-07 Thread Leizhen (ThunderTown)
On 2016/7/7 23:37, Catalin Marinas wrote: > On Thu, Jul 07, 2016 at 08:09:04PM +0800, Zhen Lei wrote: >> At present, PG_dcache_clean is only cleared when the related huge page >> is about to be freed. But sometimes, there maybe a process is in charge >> to copy binary codes into a shared memory,

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

2016-07-08 Thread Leizhen (ThunderTown)
On 2016/7/8 21:54, Catalin Marinas wrote: > On Fri, Jul 08, 2016 at 11:36:57AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/7/7 23:37, Catalin Marinas wrote: >>> On Thu, Jul 07, 2016 at 08:09:04PM +0800, Zhen Lei wrote: >>>> At present, PG_dcache_clean is only

Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap

2016-07-11 Thread Leizhen (ThunderTown)
On 2016/7/9 0:13, Catalin Marinas wrote: > On Fri, Jul 08, 2016 at 11:24:26PM +0800, Leizhen (ThunderTown) wrote: >> On 2016/7/8 21:54, Catalin Marinas wrote: >>> On Fri, Jul 08, 2016 at 11:36:57AM +0800, Leizhen (ThunderTown) wrote: >>>> On 2016/7/7 23:37, Catal

Re: [PATCH 1/1] arm64/dma-mapping: remove an unnecessary conversion

2016-03-15 Thread Leizhen (ThunderTown)
On 2016/3/15 23:37, Catalin Marinas wrote: > On Tue, Mar 15, 2016 at 10:12:11AM +0800, Zhen Lei wrote: >> 1. In swiotlb_alloc_coherent, the branch of __get_free_pages. Directly >>return vaddr on success, and pass vaddr to free_pages on failure. >> 2. So, we can directly transparent pass

Re: [PATCH 1/1] arm64/dma-mapping: remove an unnecessary conversion

2016-03-19 Thread Leizhen (ThunderTown)
On 2016/3/16 9:56, Leizhen (ThunderTown) wrote: > > > On 2016/3/15 23:37, Catalin Marinas wrote: >> On Tue, Mar 15, 2016 at 10:12:11AM +0800, Zhen Lei wrote: >>> 1. In swiotlb_alloc_coherent, the branch of __get_free_pages. Directly >>>return vaddr on succ

Re: [PATCH 1/1] arm64/dma-mapping: remove an unnecessary conversion

2016-03-19 Thread Leizhen (ThunderTown)
On 2016/3/17 19:59, Catalin Marinas wrote: > On Thu, Mar 17, 2016 at 07:06:27PM +0800, Leizhen (ThunderTown) wrote: >> On 2016/3/16 9:56, Leizhen (ThunderTown) wrote: >>> On 2016/3/15 23:37, Catalin Marinas wrote: >>>> On Tue, Mar 15, 2016 at 10:12:11AM +0800, Zh

Re: Suspicious error for CMA stress test

2016-03-07 Thread Leizhen (ThunderTown)
On 2016/3/7 12:34, Joonsoo Kim wrote: > On Fri, Mar 04, 2016 at 03:35:26PM +0800, Hanjun Guo wrote: >> On 2016/3/4 14:38, Joonsoo Kim wrote: >>> On Fri, Mar 04, 2016 at 02:05:09PM +0800, Hanjun Guo wrote: On 2016/3/4 12:32, Joonsoo Kim wrote: > On Fri, Mar 04, 2016 at 11:02:33AM +0900,

Re: [PATCH 1/1] dma-mapping: to avoid exception when cpu_addr is NULL

2016-03-07 Thread Leizhen (ThunderTown)
Suppose: CONFIG_SPARSEMEM is opened. CONFIG_DMA_API_DEBUG or CONFIG_CMA is opened. Then virt_to_page or phys_to_page will be called. Finally, in __pfn_to_page, __sec = __pfn_to_section(__pfn) is NULL. So access section->section_mem_map will trigger exception. - #define

Re: [PATCH 1/1] dma-mapping: to avoid exception when cpu_addr is NULL

2016-03-07 Thread Leizhen (ThunderTown)
On 2016/3/7 19:41, One Thousand Gnomes wrote: > On Mon, 7 Mar 2016 17:21:25 +0800 > Zhen Lei wrote: > >> Do this to keep consistent with kfree, which tolerate ptr is NULL. >> >> Signed-off-by: Zhen Lei > > This is inlined code so you are adding extra logic to every single > instance of a

Re: [PATCH 1/1] dma-mapping: to avoid exception when cpu_addr is NULL

2016-03-07 Thread Leizhen (ThunderTown)
On 2016/3/8 6:59, Andrew Morton wrote: > On Mon, 7 Mar 2016 18:43:47 +0800 "Leizhen (ThunderTown)" > wrote: > >> Suppose: >> CONFIG_SPARSEMEM is opened. >> CONFIG_DMA_API_DEBUG or CONFIG_CMA is opened. >> >> Then virt_to_page or phys_

Re: Suspicious error for CMA stress test

2016-03-07 Thread Leizhen (ThunderTown)
On 2016/3/8 2:42, Laura Abbott wrote: > On 03/07/2016 12:16 AM, Leizhen (ThunderTown) wrote: >> >> >> On 2016/3/7 12:34, Joonsoo Kim wrote: >>> On Fri, Mar 04, 2016 at 03:35:26PM +0800, Hanjun Guo wrote: >>>> On 2016/3/4 14:38, Joonsoo Kim wrote: >

Re: [PATCH 2/2] PCI: generic: add description of property "interrupt-skip-mask"

2016-02-25 Thread Leizhen (ThunderTown)
On 2016/2/25 20:20, Mark Rutland wrote: > Hi, > > In future, please send the binding document first in a series, per point > 3 of Documentation/devicetree/bindings/submitting-patches.txt. It makes > review easier/faster. Thank you for your reminding. > > On Thu, Feb 25, 2016 at 07:53:28PM

Re: [PATCH v4 12/14] arm64/numa: remove some useless code

2016-06-07 Thread Leizhen (ThunderTown)
On 2016/6/7 16:28, Ganapatrao Kulkarni wrote: > On Tue, Jun 7, 2016 at 1:38 PM, Zhen Lei wrote: >> 1. Currently only cpu0 set on cpu_possible_mask and percpu areas have not >>been initialized. >> 2. No reason to limit cpu0 must belongs to node0. > > even smp init assumes cpu0/boot

Re: [PATCH v4 11/14] arm64/numa: support HAVE_MEMORYLESS_NODES

2016-06-07 Thread Leizhen (ThunderTown)
On 2016/6/7 16:31, Ganapatrao Kulkarni wrote: > On Tue, Jun 7, 2016 at 1:38 PM, Zhen Lei wrote: >> Some numa nodes may have no memory. For example: >> 1. cpu0 on node0 >> 2. cpu1 on node1 >> 3. device0 access the momory from node0 and node1 take the same time. > > i am wondering, if access to

Re: [PATCH v4 11/14] arm64/numa: support HAVE_MEMORYLESS_NODES

2016-06-07 Thread Leizhen (ThunderTown)
On 2016/6/7 22:01, Ganapatrao Kulkarni wrote: > On Tue, Jun 7, 2016 at 6:27 PM, Leizhen (ThunderTown) > wrote: >> >> >> On 2016/6/7 16:31, Ganapatrao Kulkarni wrote: >>> On Tue, Jun 7, 2016 at 1:38 PM, Zhen Lei wrote: >>>> Some numa nodes may have

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-24 Thread Leizhen (ThunderTown)
On 2016/5/24 19:37, Mark Rutland wrote: > On Tue, May 24, 2016 at 07:16:37PM +0800, Zhen Lei wrote: >> When we ran mprotect04(a test case in LTP) infinitely, it would always >> failed after a few seconds. The case can be described briefly that: copy >> a empty function from code area into a new

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-24 Thread Leizhen (ThunderTown)
On 2016/5/25 9:20, Leizhen (ThunderTown) wrote: > > > On 2016/5/24 21:02, Catalin Marinas wrote: >> On Tue, May 24, 2016 at 08:19:05PM +0800, Leizhen (ThunderTown) wrote: >>> On 2016/5/24 19:37, Mark Rutland wrote: >>>> On Tue, May 24, 2016 at 07:16:37PM

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-25 Thread Leizhen (ThunderTown)
On 2016/5/25 18:50, Catalin Marinas wrote: > On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/5/25 9:20, Leizhen (ThunderTown) wrote: >>> On 2016/5/24 21:02, Catalin Marinas wrote: >>>> On Tue, May 24, 2016 at 08:19:05PM +080

Re: [PATCH 1/1] arm64: fix flush_cache_range

2016-05-26 Thread Leizhen (ThunderTown)
On 2016/5/25 18:50, Catalin Marinas wrote: > On Wed, May 25, 2016 at 11:36:38AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/5/25 9:20, Leizhen (ThunderTown) wrote: >>> On 2016/5/24 21:02, Catalin Marinas wrote: >>>> On Tue, May 24, 2016 at 08:19:05PM +080

Re: [PATCH 3/3] arm64/numa: fix type info

2016-05-26 Thread Leizhen (ThunderTown)
On 2016/5/27 1:12, David Daney wrote: > The current patch to correct this problem is here: > > https://lkml.org/lkml/2016/5/24/679 > > Since v7 of the ACPI/NUMA patches are likely going to be added to linux-next > as soon as the current merge window ends, further simplifications of the >

Re: [PATCH 2/3] of/numa: fix a memory@ dt node can only contains one memory block

2016-05-26 Thread Leizhen (ThunderTown)
On 2016/5/26 21:13, Rob Herring wrote: > On Thu, May 26, 2016 at 10:43:58AM +0800, Zhen Lei wrote: >> For a normal memory@ devicetree node, its reg property can contains more >> memory blocks. >> >> Because we don't known how many memory blocks maybe contained, so we try >> from index=0,

Re: [PATCH 2/3] of/numa: fix a memory@ dt node can only contains one memory block

2016-05-27 Thread Leizhen (ThunderTown)
On 2016/5/27 12:20, Rob Herring wrote: > On Thu, May 26, 2016 at 10:36 PM, Leizhen (ThunderTown) > wrote: >> >> >> On 2016/5/26 21:13, Rob Herring wrote: >>> On Thu, May 26, 2016 at 10:43:58AM +0800, Zhen Lei wrote: >>>> For a normal memory@ device

Re: [PATCH v4 11/14] arm64/numa: support HAVE_MEMORYLESS_NODES

2016-06-08 Thread Leizhen (ThunderTown)
On 2016/6/8 12:45, Ganapatrao Kulkarni wrote: > On Wed, Jun 8, 2016 at 7:46 AM, Leizhen (ThunderTown) > wrote: >> >> >> On 2016/6/7 22:01, Ganapatrao Kulkarni wrote: >>> On Tue, Jun 7, 2016 at 6:27 PM, Leizhen (ThunderTown) >>> wrote: >>>>

Re: [PATCH v4 00/14] fix some type infos and bugs for arm64/of numa

2016-06-08 Thread Leizhen (ThunderTown)
On 2016/6/7 21:58, Will Deacon wrote: > On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote: >> v3 -> v4: >> 1. Packed three patches of Kefeng Wang, patch6-8. >> 2. Add 6 new patches(9-15) to enhance the numa on arm64. >> >> v2 -> v3: >> 1. Adjust patch2 and patch5 according to Matthias

Re: [PATCH v2 5/5] arm64/numa: avoid inconsistent information to be printed

2016-05-31 Thread Leizhen (ThunderTown)
On 2016/5/31 17:07, Matthias Brugger wrote: > > > On 28/05/16 11:22, Zhen Lei wrote: >> numa_init(of_numa_init) may returned error because of numa configuration >> error. So "No NUMA configuration found" is inaccurate. In fact, specific >> configuration error information should be immediately

Re: [PATCH v2 5/5] arm64/numa: avoid inconsistent information to be printed

2016-05-31 Thread Leizhen (ThunderTown)
On 2016/5/31 19:27, Leizhen (ThunderTown) wrote: > > > On 2016/5/31 17:07, Matthias Brugger wrote: >> >> >> On 28/05/16 11:22, Zhen Lei wrote: >>> numa_init(of_numa_init) may returned error because of numa configuration >>> error. So "N

Re: [PATCH v2 2/5] of/numa: fix a memory@ node can only contains one memory block

2016-06-01 Thread Leizhen (ThunderTown)
On 2016/6/2 4:13, Rob Herring wrote: > On Sat, May 28, 2016 at 4:22 AM, Zhen Lei wrote: >> For a normal memory@ devicetree node, its reg property can contains more >> memory blocks. >> >> Because we don't known how many memory blocks maybe contained, so we try >> from index=0, increase 1 until

Re: [PATCH v2 2/5] of/numa: fix a memory@ node can only contains one memory block

2016-06-05 Thread Leizhen (ThunderTown)
On 2016/6/3 17:45, Will Deacon wrote: > On Thu, Jun 02, 2016 at 09:36:40AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/6/2 4:13, Rob Herring wrote: >>> I believe you still need this and not the one above. You only need it >>> within the loop if you return. Otherwise

Re: [PATCH v3 3/5] arm64/numa: add nid check for memory block

2016-06-05 Thread Leizhen (ThunderTown)
On 2016/6/3 17:52, Will Deacon wrote: > On Thu, Jun 02, 2016 at 10:28:09AM +0800, Zhen Lei wrote: >> Use the same tactic to cpu and numa-distance nodes. > > Sorry, I don't understand... :/ In function of_numa_parse_cpu_nodes: for_each_child_of_node(cpus, np) { ... r =

Re: [PATCH v3 5/5] arm64/numa: avoid inconsistent information to be printed

2016-06-05 Thread Leizhen (ThunderTown)
On 2016/6/3 17:55, Will Deacon wrote: > On Thu, Jun 02, 2016 at 10:28:11AM +0800, Zhen Lei wrote: >> numa_init(of_numa_init) may returned error because of numa configuration >> error. So "No NUMA configuration found" is inaccurate. In fact, specific >> configuration error information should be

Re: [PATCH 2/2] arm64: to allow EFI_RTC can be selected on ARM64

2015-09-28 Thread Leizhen (ThunderTown)
On 2015/9/28 15:35, Arnd Bergmann wrote: > On Monday 28 September 2015 13:34:38 Zhen Lei wrote: >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index 07d1811..25cec57 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -85,7 +85,7 @@ config ARM64 >> select

Re: [PATCH 2/2] arm64: to allow EFI_RTC can be selected on ARM64

2015-09-28 Thread Leizhen (ThunderTown)
On 2015/9/28 15:40, Ard Biesheuvel wrote: > On 28 September 2015 at 06:34, Zhen Lei wrote: >> Now, ARM64 is also support EFI startup. We hope use EFI runtime services >> to get/set current time and date. >> >> RTC_LIB only controls some configs in drivers/char/Kconfig(included >> EFI_RTC), and

Re: [PATCH 2/2] arm64: to allow EFI_RTC can be selected on ARM64

2015-09-28 Thread Leizhen (ThunderTown)
On 2015/9/28 16:42, Arnd Bergmann wrote: > On Monday 28 September 2015 16:29:57 Leizhen wrote: >> >> On 2015/9/28 15:35, Arnd Bergmann wrote: >>> On Monday 28 September 2015 13:34:38 Zhen Lei wrote: diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 07d1811..25cec57 100644

Re: [PATCH v2 1/2] arm64: dts: broadcom: clear the warnings caused by empty dma-ranges

2020-10-17 Thread Leizhen (ThunderTown)
On 2020/10/17 3:27, Florian Fainelli wrote: > On 10/16/20 11:23 AM, Arnd Bergmann wrote: >> On Fri, Oct 16, 2020 at 6:48 PM Florian Fainelli >> wrote: >>> On 10/16/20 4:01 AM, Arnd Bergmann wrote: On Fri, Oct 16, 2020 at 11:09 AM Zhen Lei wrote: > > Suggested-by: Arnd

Re: [PATCH 0/4] dt-bindings: media: eliminate yamllint warnings

2020-12-07 Thread Leizhen (ThunderTown)
On 2020/12/7 17:08, Jacopo Mondi wrote: > Hi Zhen, > > On Mon, Dec 07, 2020 at 12:23:56PM +0800, Zhen Lei wrote: >> These patches are based on the latest linux-next code. >> >> Zhen Lei (4): >> dt-bindings: media: adv7604: eliminate yamllint warnings >> dt-bindings: media: nokia,smia:

Re: [PATCH v2 1/3] reset: hisilicon: correct vendor prefix

2020-12-07 Thread Leizhen (ThunderTown)
On 2020/12/8 7:08, Rob Herring wrote: > On Fri, Dec 04, 2020 at 09:42:34AM +0800, Zhen Lei wrote: >> The vendor prefix of "Hisilicon Limited" is "hisilicon", it is clearly >> stated in "vendor-prefixes.yaml". > > Yes, but you can't fix this as changing it breaks compability between > DTBs and

Re: [PATCH v2 3/3] dt-bindings: reset: convert Hisilicon reset controller bindings to json-schema

2020-12-07 Thread Leizhen (ThunderTown)
On 2020/12/8 7:10, Rob Herring wrote: > On Fri, Dec 04, 2020 at 09:42:36AM +0800, Zhen Lei wrote: >> Convert the Hisilicon reset controller binding to DT schema format using >> json-schema. >> >> Signed-off-by: Zhen Lei >> --- >> .../bindings/reset/hisilicon,hi3660-reset.txt | 44

<    1   2   3   4   5   >