Re: [PATCH 2/2] xfs: remove the extra processing of zero size in xfs_idata_realloc()

2020-11-24 Thread Leizhen (ThunderTown)
On 2020/11/24 19:52, Christoph Hellwig wrote: > On Tue, Nov 24, 2020 at 06:45:31PM +0800, Zhen Lei wrote: >> krealloc() does the free operation when the parameter new_size is 0, with >> ZERO_SIZE_PTR returned. Because all other places use NULL to check whether >> if_data is available or not, so

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

2020-12-03 Thread Leizhen (ThunderTown)
On 2020/12/3 20:54, Philipp Zabel wrote: > On Thu, 2020-12-03 at 20:02 +0800, Zhen Lei wrote: >> The vendor prefix of "Hisilicon Limited" is "hisilicon", it is clearly >> stated in "vendor-prefixes.yaml". >> >> Fixes: 1527058736fa ("reset: hisilicon: add reset-hi3660") >> Signed-off-by: Zhen Lei

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

2020-12-03 Thread Leizhen (ThunderTown)
Sorry, Forgot to say: This patch is based on the latest linux-next code. On 2020/12/4 10:42, Zhen Lei wrote: > There're too many people, I just send to the maintainer, reviewer, supporter. > > Eliminate below warnings: > ./Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml:32:13: [warning

Re: [PATCH 5/6] ARM: dts: mmp2-olpc-xo-1-75: explicitly add #address-cells=<0> for slave mode

2020-12-03 Thread Leizhen (ThunderTown)
Hi everybody: Can somebody apply this patch? When I do any YAML dtbs_check on arm, below Warnings always reported. arch/arm/boot/dts/mmp2.dtsi:472.23-480.6: Warning (spi_bus_bridge): /soc/apb@d400/spi@d4037000: incorrect #address-cells for SPI bus also defined at arch/arm/boot/dts/mmp2-o

Re: [PATCH 1/1] dt-bindings: eliminate yamllint warnings

2020-12-05 Thread Leizhen (ThunderTown)
On 2020/12/5 1:41, Mark Brown wrote: > On Fri, Dec 04, 2020 at 10:42:26AM +0800, Zhen Lei wrote: >> All warnings are related only to "wrong indentation", except one: >> Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml:4:1: \ >> [error] missing document start "---" (document-start) > >

Re: [PATCH 1/5] media: dt-bindings: add the required property 'additionalProperties'

2020-12-05 Thread Leizhen (ThunderTown)
On 2020/12/4 18:56, Philipp Zabel wrote: > On Fri, 2020-12-04 at 17:38 +0800, Zhen Lei wrote: >> When I do dt_binding_check for any YAML file, below wanring is always >> reported: >> >> xxx/media/coda.yaml: 'additionalProperties' is a required property >> xxx/media/coda.yaml: ignoring, error in

Re: [PATCH 1/1] device-dax: avoid an unnecessary check in alloc_dev_dax_range()

2020-12-17 Thread Leizhen (ThunderTown)
On 2020/12/18 11:10, Dan Williams wrote: > On Fri, Nov 20, 2020 at 1:23 AM Zhen Lei wrote: >> >> Swap the calling sequence of krealloc() and __request_region(), call the >> latter first. In this way, the value of dev_dax->nr_range does not need to >> be considered when __request_region() failed

Re: [PATCH 1/1] device-dax: avoid an unnecessary check in alloc_dev_dax_range()

2020-12-17 Thread Leizhen (ThunderTown)
On 2020/11/20 17:22, Zhen Lei wrote: > Swap the calling sequence of krealloc() and __request_region(), call the > latter first. In this way, the value of dev_dax->nr_range does not need to > be considered when __request_region() failed. > > Signed-off-by: Zhen Lei > --- > drivers/dax/bus.c |

Re: [PATCH] device-dax: Fix range release

2020-12-18 Thread Leizhen (ThunderTown)
On 2020/12/19 10:41, Dan Williams wrote: > There are multiple locations that open-code the release of the last > range in a device-dax instance. Consolidate this into a new > dev_dax_trim_range() helper. > > This also addresses a kmemleak report: > > # cat /sys/kernel/debug/kmemleak > [..] > u

Re: [PATCH 1/2] perf/smmuv3: Don't reserve the register space that overlaps with the SMMUv3

2021-01-20 Thread Leizhen (ThunderTown)
On 2021/1/20 11:37, Leizhen (ThunderTown) wrote: > > > On 2021/1/19 20:32, Robin Murphy wrote: >> On 2021-01-19 01:59, Zhen Lei wrote: >>> Some SMMUv3 implementation embed the Perf Monitor Group Registers (PMCG) >>> inside the first 64kB region of the SMMU

Re: [PATCH 1/2] perf/smmuv3: Don't reserve the register space that overlaps with the SMMUv3

2021-01-20 Thread Leizhen (ThunderTown)
On 2021/1/20 21:27, Robin Murphy wrote: > On 2021-01-20 09:26, Leizhen (ThunderTown) wrote: >> >> >> On 2021/1/20 11:37, Leizhen (ThunderTown) wrote: >>> >>> >>> On 2021/1/19 20:32, Robin Murphy wrote: >>>> On 2021-01-19 01:59, Zhe

Re: [PATCH 1/2] perf/smmuv3: Don't reserve the register space that overlaps with the SMMUv3

2021-01-20 Thread Leizhen (ThunderTown)
On 2021/1/20 23:54, Robin Murphy wrote: > On 2021-01-20 14:14, Leizhen (ThunderTown) wrote: >> >> >> On 2021/1/20 21:27, Robin Murphy wrote: >>> On 2021-01-20 09:26, Leizhen (ThunderTown) wrote: >>>> >>>> >>>> On 2021/1/20 11:37,

Re: [PATCH 2/2] Revert "iommu/arm-smmu-v3: Don't reserve implementation defined register space"

2021-01-20 Thread Leizhen (ThunderTown)
On 2021/1/20 23:02, Robin Murphy wrote: > On 2021-01-19 01:59, Zhen Lei wrote: >> This reverts commit 52f3fab0067d6fa9e99c1b7f63265dd48ca76046. >> >> This problem has been fixed by another patch. The original method had side >> effects, it was not mapped to the user-specified resource size. The

Re: [PATCH 2/2] Revert "iommu/arm-smmu-v3: Don't reserve implementation defined register space"

2021-01-21 Thread Leizhen (ThunderTown)
On 2021/1/21 20:50, Robin Murphy wrote: > On 2021-01-21 02:04, Leizhen (ThunderTown) wrote: >> >> >> On 2021/1/20 23:02, Robin Murphy wrote: >>> On 2021-01-19 01:59, Zhen Lei wrote: >>>> This reverts commit 52f3fab0067d6fa9e99c1b7f63265dd48ca76046

Re: [PATCH 1/1] iommu/arm-smmu-v3: add support for BBML

2021-01-22 Thread Leizhen (ThunderTown)
On 2021/1/22 21:00, Robin Murphy wrote: > On 2021-01-22 12:51, Will Deacon wrote: >> On Thu, Nov 26, 2020 at 11:42:30AM +0800, Zhen Lei wrote: >>> When changing from a set of pages/smaller blocks to a larger block for an >>> address, the software should follow the sequence of BBML processing. >>

Re: [PATCH v2] dt-bindings: leds: Document commonly used LED triggers

2021-01-26 Thread Leizhen (ThunderTown)
Hi Manivannan: Do you have time to prepare v3? Hope it can be applied into v5.12 On 2020/12/15 6:36, Rob Herring wrote: > On Thu, Dec 10, 2020 at 01:54:49PM +0530, Manivannan Sadhasivam wrote: >> This commit documents the LED triggers used commonly in the SoCs. Not >> all triggers are documente

Re: [PATCH v3 2/4] arm64: dts: correct vendor prefix hisi to hisilicon

2021-01-26 Thread Leizhen (ThunderTown)
On 2021/1/27 6:23, Arnd Bergmann wrote: > On Tue, Dec 8, 2020 at 1:46 PM Zhen Lei wrote: >> >> The vendor prefix of "Hisilicon Limited" is "hisilicon", it is clearly >> stated in "vendor-prefixes.yaml". >> >> Fixes: 35ca8168133c ("arm64: dts: Add dts files for Hisilicon Hi3660 SoC") >> Fixes: d

Re: [PATCH 1/1] iommu/arm-smmu-v3: add support for BBML

2021-01-26 Thread Leizhen (ThunderTown)
On 2021/1/26 18:12, Will Deacon wrote: > On Mon, Jan 25, 2021 at 08:23:40PM +, Robin Murphy wrote: >> Now we probably will need some degreee of BBML feature awareness for the >> sake of SVA if and when we start using it for CPU pagetables, but I still >> cannot see any need to consider it in

Re: [PATCH 1/1] iommu/arm-smmu-v3: Use DEFINE_RES_MEM() to simplify code

2021-01-26 Thread Leizhen (ThunderTown)
I've sent another set of patches. https://lkml.org/lkml/2021/1/26/1065 If those patches are acceptable, then this one should be ignored. On 2021/1/22 21:14, Zhen Lei wrote: > No functional change. > > Signed-off-by: Zhen Lei > --- > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 6 +- > 1 f

Re: [PATCH 1/1] iommu/arm-smmu-v3: add support for BBML

2021-01-23 Thread Leizhen (ThunderTown)
On 2021/1/22 20:51, Will Deacon wrote: > On Thu, Nov 26, 2020 at 11:42:30AM +0800, Zhen Lei wrote: >> When changing from a set of pages/smaller blocks to a larger block for an >> address, the software should follow the sequence of BBML processing. >> >> When changing from a block to a set of pag

Re: [PATCH 1/1] iommu/arm-smmu-v3: add support for BBML

2021-01-23 Thread Leizhen (ThunderTown)
On 2021/1/22 21:00, Robin Murphy wrote: > On 2021-01-22 12:51, Will Deacon wrote: >> On Thu, Nov 26, 2020 at 11:42:30AM +0800, Zhen Lei wrote: >>> When changing from a set of pages/smaller blocks to a larger block for an >>> address, the software should follow the sequence of BBML processing. >>

Re: [PATCH 1/1] iommu/arm-smmu-v3: Use DEFINE_RES_MEM() to simplify code

2021-01-27 Thread Leizhen (ThunderTown)
On 2021/1/27 17:23, Will Deacon wrote: > On Wed, Jan 27, 2021 at 10:05:50AM +0800, Leizhen (ThunderTown) wrote: >> I've sent another set of patches. https://lkml.org/lkml/2021/1/26/1065 >> If those patches are acceptable, then this one should be ignored. > > I've

Re: [PATCH v5 0/4] ARM: Add support for Hisilicon Kunpeng L3 cache controller

2021-01-27 Thread Leizhen (ThunderTown)
Hi Russell and Arnd: Do you have time to review it? On 2021/1/16 11:27, Zhen Lei wrote: > v4 --> v5: > 1. Add SoC macro ARCH_KUNPENG50X, and the Kunpeng L3 cache controller only > enabled >on that platform. > 2. Require the compatible string of the Kunpeng L3 cache controller must have >

Re: [PATCH 1/1] perf diff: fix error return value in __cmd_diff()

2020-11-27 Thread Leizhen (ThunderTown)
Hi everybody: Can any one review it? On 2020/11/24 18:36, Zhen Lei wrote: > An appropriate return value should be set on the failed path. > > Reported-by: Hulk Robot > Signed-off-by: Zhen Lei > --- > tools/perf/builtin-diff.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > d

Re: [PATCH 1/1] perf diff: fix error return value in __cmd_diff()

2020-11-27 Thread Leizhen (ThunderTown)
On 2020/11/28 1:25, Arnaldo Carvalho de Melo wrote: > Em Fri, Nov 27, 2020 at 02:22:02PM -0300, Arnaldo Carvalho de Melo escreveu: >> Em Fri, Nov 27, 2020 at 10:35:37PM +0900, Namhyung Kim escreveu: >>> On Tue, Nov 24, 2020 at 7:37 PM Zhen Lei wrote: > An appropriate return value should b

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 tha

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 m

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 > info

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, increase

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 1/1] tty/serial: to support 8250 earlycon can be enabled independently

2016-05-16 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 to

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 en

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 device

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 +080

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/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 vaddr

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, Zhen

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 v2 0/2] iommu/iova: enhance the rcache optimization

2019-08-23 Thread Leizhen (ThunderTown)
Hi all, Can anyone help review it? On 2019/8/15 20:11, Zhen Lei wrote: > v1 --> v2 > 1. I did not chagne the patches but added this cover-letter. > 2. Add a batch of reviewers base on >9257b4a206fc ("iommu/iova: introduce per-cpu caching to iova allocation") > 3. I described the problem I m

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: >>>> &

[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 n

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 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 e

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 p

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 memoryle

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 t

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() cal

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. > > Signed

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/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 near

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 rb_nex

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 b/arch/arm64/mm/nu

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, b

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 i

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 num

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 deleti

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 class

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) - set_cpu_numa_

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 processor

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 b

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 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 Brug

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 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 = of_property_

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 im

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, J

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 __pfn_to_page(pfn

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 call

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] 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 PERF

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 w

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 0/3] clean up some functions in mm/swap_slots.c

2020-07-08 Thread Leizhen (ThunderTown)
Hi, all: Are these patches acceptable? All these three patches are "Acked-by: Tim Chen " two months ago. On 2020/4/30 14:11, Zhen Lei wrote: > When I studied the code of mm/swap_slots.c, I found some places can be > improved. > > Zhen Lei (3): > mm/swap: simplify alloc_swap_slot_cache() >

Re: [PATCH v3 0/7] bugfix and optimize for drivers/nvdimm

2020-08-26 Thread Leizhen (ThunderTown)
Hi all: Any comment? I want to merge patches 1 and 2 into one, then send other patches separately. On 2020/8/20 10:16, Zhen Lei wrote: > v2 --> v3: > 1. Fix spelling error of patch 1 subject: memmory --> memory > 2. Add "Reviewed-by: Oliver O'Halloran " into patch 1 > 3. Rewrite patch descriptio

Re: [PATCH 3/4] libnvdimm: eliminate two unnecessary zero initializations in badrange.c

2020-08-26 Thread Leizhen (ThunderTown)
I will drop this patch, because badrange_add() is unlikely to be called. There's no need to care about trivial performance improvements. On 2020/8/20 22:30, Zhen Lei wrote: > Currently, the "struct badrange_entry" has three members: start, length, > list. In append_badrange_entry(), "start" and "l

Re: [PATCH v3 5/7] libnvdimm: reduce an unnecessary if branch in nd_region_activate()

2020-08-27 Thread Leizhen (ThunderTown)
I will drop this patch, because I have a doubt: Suppose the nd_region->ndr_mappings is 4, and for each nd_region->mapping[], the value of num_flush is "0, 0, 4, 0", so the flush_data_size is "1 + 1 + 5 + 1", * sizeof(void *). But in ndrd_get_flush_wpq() or ndrd_set_flush_wpq(), the expression is "

Re: [PATCH v4 12/20] dt-bindings: arm: hisilicon: convert hisilicon,hi3798cv200-perictrl bindings to json-schema

2020-09-29 Thread Leizhen (ThunderTown)
On 2020/9/29 11:18, Leizhen (ThunderTown) wrote: > > > On 2020/9/29 3:14, Rob Herring wrote: >> On Mon, Sep 28, 2020 at 11:13:16PM +0800, Zhen Lei wrote: >>> Convert the Hisilicon Hi3798CV200 Peripheral Controller binding to DT >>> schema format using json-sc

Re: [PATCH v4 12/20] dt-bindings: arm: hisilicon: convert hisilicon,hi3798cv200-perictrl bindings to json-schema

2020-09-29 Thread Leizhen (ThunderTown)
On 2020/9/29 17:21, Leizhen (ThunderTown) wrote: > > > On 2020/9/29 11:18, Leizhen (ThunderTown) wrote: >> >> >> On 2020/9/29 3:14, Rob Herring wrote: >>> On Mon, Sep 28, 2020 at 11:13:16PM +0800, Zhen Lei wrote: >>>> Convert the Hisilicon

Re: [PATCH v5 15/17] dt-bindings: arm: hisilicon: convert Hi6220 domain controller bindings to json-schema

2020-09-29 Thread Leizhen (ThunderTown)
Hi, Rob: I'm so glad to see you applied my patches in this morning. However, this patch is not applied and without any comment. Did you miss it? On 2020/9/29 22:14, Zhen Lei wrote: > Convert the Hisilicon Hi6220 domain controllers binding to DT schema > format using json-schema. All of them are

Re: [PATCH v4 12/20] dt-bindings: arm: hisilicon: convert hisilicon,hi3798cv200-perictrl bindings to json-schema

2020-09-29 Thread Leizhen (ThunderTown)
On 2020/9/29 21:52, Rob Herring wrote: > On Tue, Sep 29, 2020 at 8:25 AM Leizhen (ThunderTown) > wrote: >> >> >> >> On 2020/9/29 17:21, Leizhen (ThunderTown) wrote: >>> >>> >>> On 2020/9/29 11:18, Leizhen (ThunderTown) wrote: >>

Re: [PATCH v5 15/17] dt-bindings: arm: hisilicon: convert Hi6220 domain controller bindings to json-schema

2020-09-29 Thread Leizhen (ThunderTown)
On 2020/9/30 9:38, Leizhen (ThunderTown) wrote: > Hi, Rob: > I'm so glad to see you applied my patches in this morning. However, this > patch > is not applied and without any comment. Did you miss it? Oh, I got it, missed the property "#reset-cells". What a sham

Re: [PATCH v6 01/17] dt-bindings: mfd: syscon: add some compatible strings for Hisilicon

2020-09-30 Thread Leizhen (ThunderTown)
On 2020/9/30 15:11, Lee Jones wrote: > On Wed, 30 Sep 2020, Zhen Lei wrote: > >> Add some compatible strings for Hisilicon controllers: >> hisilicon,hi6220-sramctrl --> Hi6220 SRAM controller >> hisilicon,pcie-sas-subctrl --> HiP05/HiP06 PCIe-SAS subsystem controller >> hisilicon,peri-subctrl

Re: [PATCH v6 01/17] dt-bindings: mfd: syscon: add some compatible strings for Hisilicon

2020-10-10 Thread Leizhen (ThunderTown)
On 2020/10/1 14:59, Lee Jones wrote: > On Wed, 30 Sep 2020, Leizhen (ThunderTown) wrote: > >> >> >> On 2020/9/30 15:11, Lee Jones wrote: >>> On Wed, 30 Sep 2020, Zhen Lei wrote: >>> >>>> Add some compatible strings for Hisilicon contro

Re: [PATCH v6 14/17] dt-bindings: arm: hisilicon: convert hisilicon,hip04-bootwrapper bindings to json-schema

2020-10-10 Thread Leizhen (ThunderTown)
On 2020/10/1 14:41, Krzysztof Kozlowski wrote: > On Wed, Sep 30, 2020 at 11:17:09AM +0800, Zhen Lei wrote: >> Convert the Hisilicon Bootwrapper boot method binding to DT schema format >> using json-schema. >> >> The property boot-method contains two groups of physical address range >> informatio

Re: linux-next: manual merge of the devicetree tree with the mfd tree

2020-10-10 Thread Leizhen (ThunderTown)
On 2020/10/1 20:31, Rob Herring wrote: > On Thu, Oct 1, 2020 at 1:26 AM Krzysztof Kozlowski wrote: >> >> On Thu, 1 Oct 2020 at 08:22, Stephen Rothwell wrote: >>> >>> Hi all, >>> >>> Today's linux-next merge of the devicetree tree got a conflict in: >>> >>> Documentation/devicetree/bindings/m

<    1   2   3   4   >