Re: [PATCH v2 1/3] iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock confliction

On 2017/10/18 20:58, Will Deacon wrote: > Hi Thunder, > > On Tue, Sep 12, 2017 at 09:00:36PM +0800, Zhen Lei wrote: >> Because all TLBI commands should be followed by a SYNC command, to make >> sure that it has been completely finished. So we can just add the TLBI >> commands into the queue,

Re: [PATCH 1/1] Input: ims-pcu - fix typo in an error log

On 2017/11/24 15:17, Joe Perches wrote: > On Fri, 2017-11-24 at 14:59 +0800, Zhen Lei wrote: >> Tiny typo fixed in an error log. >> >> I found this when I backported the CVE-2017-16645 patch: >> ea04efee7635 ("Input: ims-psu - check if CDC union descriptor is sane") >> >> Signed-off-by: Zhen Lei

Re: [PATCH 1/1] aio: make sure the input "timeout" value is valid

On 2017/12/14 3:31, Matthew Wilcox wrote: > On Wed, Dec 13, 2017 at 11:27:00AM -0500, Jeff Moyer wrote: >> Matthew Wilcox writes: >> >>> On Wed, Dec 13, 2017 at 09:42:52PM +0800, Zhen Lei wrote: Below information is reported by a lower kernel version, and I saw the

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

SIGINFO) ? _rt : ); } On 2018/6/6 15:52, Leizhen (ThunderTown) wrote: > > > On 2018/6/5 19:24, Leizhen (ThunderTown) wrote: >> After I executed "echo 0 > /proc/sys/abi/vsyscall32" to disable vdso, the >> rt_sigaction01 test ca

[Question] Can we use SIGRTMIN when vdso disabled on X86?

After I executed "echo 0 > /proc/sys/abi/vsyscall32" to disable vdso, the rt_sigaction01 test case from ltp_2015 failed. The test case source code please refer to the attachment, and the output as blow: - ./rt_sigaction01 rt_sigaction010 TINFO : signal: 34 rt_sigaction01

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

On 2018/6/5 19:24, Leizhen (ThunderTown) wrote: > After I executed "echo 0 > /proc/sys/abi/vsyscall32" to disable vdso, the > rt_sigaction01 test case from ltp_2015 failed. > The test case source code please refer to the attachment, and

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

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?

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?

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

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

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 v5 5/5] iommu/arm-smmu-v3: add bootup option "iommu.non_strict"

On 2018/8/23 1:02, Robin Murphy wrote: > On 15/08/18 02:28, Zhen Lei wrote: >> Add a bootup option to make the system manager can choose which mode to >> be used. The default mode is strict. >> >> Signed-off-by: Zhen Lei >> --- >> Documentation/admin-guide/kernel-parameters.txt | 13

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

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 1/1] iommu/arm-smmu-v3: eliminate a potential memory corruption on Hi16xx soc

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 1/1] iommu/arm-smmu-v3: eliminate a potential memory corruption on Hi16xx soc

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 v2 1/1] iommu/arm-smmu-v3: eliminate a potential memory corruption on Hi16xx soc

On 2018/10/30 1:59, Will Deacon wrote: > On Sat, Oct 20, 2018 at 03:36:54PM +0800, Zhen Lei wrote: >> The standard GITS_TRANSLATER register in ITS is only 4 bytes, but >> Hisilicon expands the next 4 bytes to carry some IMPDEF information. That >> means, total 8 bytes data will be written to

Re: [PATCH v2 3/4] iommu/iova: Extend rbtree node caching

On 2017/8/4 3:41, Nate Watterson wrote: > Hi Robin, > > On 7/31/2017 7:42 AM, Robin Murphy wrote: >> Hi Nate, >> >> On 29/07/17 04:57, Nate Watterson wrote: >>> Hi Robin, >>> I am seeing a crash when performing very basic testing on this series >>> with a Mellanox CX4 NIC. I dug into the crash

Re: [PATCH 0/5] arm-smmu: performance optimization

On 2017/8/17 22:36, Will Deacon wrote: > Thunder, Nate, Robin, > > On Mon, Jun 26, 2017 at 09:38:45PM +0800, Zhen Lei wrote: >> I described the optimization more detail in patch 1 and 2, and patch 3-5 are >> the implementation on arm-smmu/arm-smmu-v3 of patch 2. >> >> Patch 1 is v2. In v1, I

Re: [PATCH 1/1] mm: only dispaly online cpus of the numa node

On 2017/8/28 21:13, Michal Hocko wrote: > On Fri 25-08-17 18:34:33, Will Deacon wrote: >> On Thu, Aug 24, 2017 at 10:32:26AM +0200, Michal Hocko wrote: >>> It seems this has slipped through cracks. Let's CC arm64 guys >>> >>> On Tue 20-06-17 20:43:28, Zhen Lei wrote: When I executed numactl

Re: [PATCH v2 0/3] arm-smmu: performance optimization

On 2017/9/19 12:31, Nate Watterson wrote: > Hi Leizhen, > > On 9/12/2017 9:00 AM, Zhen Lei wrote: >> v1 -> v2: >> base on (add02cfdc9bc2 "iommu: Introduce Interface for IOMMU TLB Flushing") >> >> Zhen Lei (3): >>iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock >>

Re: [PATCH v2 3/4] iommu/iova: Extend rbtree node caching

On 2017/7/31 19:42, Robin Murphy wrote: > Hi Nate, > > On 29/07/17 04:57, Nate Watterson wrote: >> Hi Robin, >> I am seeing a crash when performing very basic testing on this series >> with a Mellanox CX4 NIC. I dug into the crash a bit, and think this >> patch is the culprit, but this rcache

Re: [PATCH v2 0/4] Optimise 64-bit IOVA allocations

On 2017/8/8 20:03, Ganapatrao Kulkarni wrote: > On Wed, Jul 26, 2017 at 4:47 PM, Leizhen (ThunderTown) > wrote: >> >> >> On 2017/7/26 19:08, Joerg Roedel wrote: >>> Hi Robin. >>> >>> On Fri, Jul 21, 2017 at 12:41:57PM +0100, Robin Murphy wrote:

Re: [PATCH v2 0/4] Optimise 64-bit IOVA allocations

On 2017/8/9 11:24, Ganapatrao Kulkarni wrote: > On Wed, Aug 9, 2017 at 7:12 AM, Leizhen (ThunderTown) > wrote: >> >> >> On 2017/8/8 20:03, Ganapatrao Kulkarni wrote: >>> On Wed, Jul 26, 2017 at 4:47 PM, Leizhen (ThunderTown) >>> wrote: >>>

Re: [PATCH 1/5] iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock confliction

On 2017/8/22 23:41, Joerg Roedel wrote: > On Mon, Jun 26, 2017 at 09:38:46PM +0800, Zhen Lei wrote: >> -static int queue_insert_raw(struct arm_smmu_queue *q, u64 *ent) >> +static int queue_insert_raw(struct arm_smmu_queue *q, u64 *ent, int >> optimize) >> { >> if (queue_full(q)) >>

Re: [PATCH v2 0/4] Optimise 64-bit IOVA allocations

On 2017/7/26 19:08, Joerg Roedel wrote: > Hi Robin. > > On Fri, Jul 21, 2017 at 12:41:57PM +0100, Robin Murphy wrote: >> Hi all, >> >> In the wake of the ARM SMMU optimisation efforts, it seems that certain >> workloads (e.g. storage I/O with large scatterlists) probably remain quite >> heavily

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

On 2017/6/21 17:08, Will Deacon wrote: > On Wed, Jun 21, 2017 at 09:28:23AM +0800, Leizhen (ThunderTown) wrote: >> 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 memo

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

On 2017/6/26 21:29, Leizhen (ThunderTown) wrote: > > > On 2017/6/21 17:08, Will Deacon wrote: >> On Wed, Jun 21, 2017 at 09:28:23AM +0800, Leizhen (ThunderTown) wrote: >>> On 2017/6/20 19:35, Robin Murphy wrote: >>>> On 20/06/17 12:04, Zhen Lei wro

Re: [PATCH 1/5] iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock confliction

On 2017/6/28 17:32, Will Deacon wrote: > Hi Zhen Lei, > > Nate (CC'd), Robin and I have been working on something very similar to > this series, but this patch is different to what we had planned. More below. > > On Mon, Jun 26, 2017 at 09:38:46PM +0800, Zhen Lei wrote: >> Because all TLBI

Re: [PATCH 4/4] iommu/iova: Make dma_32bit_pfn implicit

On 2017/7/19 23:07, kbuild test robot wrote: > Hi Zhen, > > [auto build test WARNING on iommu/next] > [also build test WARNING on v4.13-rc1] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: >

Re: [PATCH 0/4] Optimise 64-bit IOVA allocations

On 2017/7/19 18:23, Robin Murphy wrote: > On 19/07/17 09:37, Ard Biesheuvel wrote: >> On 18 July 2017 at 17:57, Robin Murphy wrote: >>> Hi all, >>> >>> In the wake of the ARM SMMU optimisation efforts, it seems that certain >>> workloads (e.g. storage I/O with large scatterlists) probably

Re: [PATCH 1/1] Input: ims-pcu - fix typo in an error log

On 2017/11/24 15:17, Joe Perches wrote: > On Fri, 2017-11-24 at 14:59 +0800, Zhen Lei wrote: >> Tiny typo fixed in an error log. >> >> I found this when I backported the CVE-2017-16645 patch: >> ea04efee7635 ("Input: ims-psu - check if CDC union descriptor is sane") >> >> Signed-off-by: Zhen Lei

Re: [PATCH v2 1/1] mm: only dispaly online cpus of the numa node

On 2017/10/3 21:56, Michal Hocko wrote: > On Tue 03-10-17 14:47:26, Will Deacon wrote: >> On Mon, Oct 02, 2017 at 02:54:46PM -0700, Andrew Morton wrote: >>> On Mon, 2 Oct 2017 11:38:07 +0100 Will Deacon wrote: >>> > When I executed numactl -H(which read >

Re: [PATCH 1/1] aio: make sure the input "timeout" value is valid

On 2017/12/14 3:31, Matthew Wilcox wrote: > On Wed, Dec 13, 2017 at 11:27:00AM -0500, Jeff Moyer wrote: >> Matthew Wilcox writes: >> >>> On Wed, Dec 13, 2017 at 09:42:52PM +0800, Zhen Lei wrote: Below information is reported by a lower kernel version, and I saw the problem still exist

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

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 1/2] perf/smmuv3: Don't reserve the register space that overlaps with the SMMUv3

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 1/1] iommu/arm-smmu-v3: add support for BBML

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

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

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 2/2] Revert "iommu/arm-smmu-v3: Don't reserve implementation defined register space"

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 52f3fab0067d6fa9e99c1b7f63265dd48ca76

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

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/2] perf/smmuv3: Don't reserve the register space that overlaps with the SMMUv3

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. Since SMMU and PMCG are managed >> by two separate drivers, and this driver depends on

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

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

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: [v2] Old platforms: bring out your dead

On 2021/1/15 17:26, Arnd Bergmann wrote: > On Fri, Jan 15, 2021 at 8:08 AM Wei Xu wrote: >> On 2021/1/14 0:14, Arnd Bergmann wrote: >>> On Fri, Jan 8, 2021 at 11:55 PM Arnd Bergmann wrote: >>> * mmp -- added in 2009, DT support is active, but board files might go >>> * cns3xxx -- added in

Re: [PATCH v3 2/3] dt-bindings: arm: hisilicon: Add binding for L3 cache controller

On 2021/1/12 21:55, Arnd Bergmann wrote: > On Tue, Jan 12, 2021 at 1:35 PM Leizhen (ThunderTown) > wrote: >> On 2021/1/12 16:46, Arnd Bergmann wrote: >>> On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei wrote: >>> >>>> +--- >>>> +$id: ht

Re: [PATCH v3 2/3] dt-bindings: arm: hisilicon: Add binding for L3 cache controller

On 2021/1/13 15:44, Leizhen (ThunderTown) wrote: > > > On 2021/1/12 21:55, Arnd Bergmann wrote: >> On Tue, Jan 12, 2021 at 1:35 PM Leizhen (ThunderTown) >> wrote: >>> On 2021/1/12 16:46, Arnd Bergmann wrote: >>>> On Tue, Jan

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

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

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

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

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

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 shame! I

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

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 6/6] dt-bindings: misc: correct the property name cmd-gpios to cmd-gpio

On 2020/10/14 21:50, Rob Herring wrote: > On Wed, Oct 14, 2020 at 09:29:26AM +0800, Leizhen (ThunderTown) wrote: >> >> >> On 2020/10/14 1:32, Dan Murphy wrote: >>> Zhen >>> >>> On 10/13/20 11:08 AM, Zhen Lei wrote: >>>> The p

Re: [PATCH 2/6] dt-bindings: mfd: google,cros-ec: explicitly allow additional properties

On 2020/10/14 21:38, Rob Herring wrote: > On Wed, Oct 14, 2020 at 12:08:41AM +0800, Zhen Lei wrote: >> There are so many properties have not been described in this yaml file, >> and a lot of errors will be reported. Especially, some yaml files such as >> google,cros-ec-typec.yaml,

Re: [PATCH 6/6] dt-bindings: misc: correct the property name cmd-gpios to cmd-gpio

On 2020/10/15 15:12, Lubomir Rintel wrote: > Hi, > > On Wed, Oct 14, 2020 at 12:08:45AM +0800, Zhen Lei wrote: >> The property name used in arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts is >> cmd-gpio. >> >> arch/arm/boot/dts/mmp2-olpc-xo-1-75.dts:235: >> cmd-gpio = < 155 GPIO_ACTIVE_HIGH>; >> >>

Re: [PATCH v2 1/1] dt-bindings: misc: add support for both property names cmd-gpios and cmd-gpio

On 2020/10/15 15:01, Geert Uytterhoeven wrote: > Hi Zhen, > > Thanks for your patch! > > On Thu, Oct 15, 2020 at 6:52 AM Zhen Lei wrote: >> The definition "gpio_suffixes[] = { "gpios", "gpio" }" shows that both >> property names "cmd-gpios" and "cmd-gpio" are supported. But currently >> only

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

Hi Lubomir: Can you review this patch? The results of all other patches are clear. On 2020/10/14 0:08, Zhen Lei wrote: > Delete the old property "#address-cells" and then explicitly add it with > zero value. The value of "#size-cells" is already zero, so keep it no > change. > > Signed-off-by:

Re: [PATCH 1/2] arm64: dts: broadcom: remove an unused property dma-ranges

On 2020/10/14 22:02, Arnd Bergmann wrote: > On Wed, Oct 14, 2020 at 3:36 PM Leizhen (ThunderTown) > wrote: >> On 2020/10/14 15:38, Arnd Bergmann wrote: >>> On Wed, Oct 14, 2020 at 5:15 AM Florian Fainelli >>> wrote: >>>> On 10/12/2020 11:06 P

Re: [PATCH 1/2] arm64: dts: broadcom: remove an unused property dma-ranges

On 2020/10/16 15:06, Leizhen (ThunderTown) wrote: > > > On 2020/10/14 22:02, Arnd Bergmann wrote: >> On Wed, Oct 14, 2020 at 3:36 PM Leizhen (ThunderTown) >> wrote: >>> On 2020/10/14 15:38, Arnd Bergmann wrote: >>>> On Wed, Oct 14, 2020 at 5:15 AM

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

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

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

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

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

Re: [PATCH v6 11/17] dt-bindings: arm: hisilicon: convert hisilicon,cpuctrl bindings to json-schema

On 2020/10/1 14:40, Krzysztof Kozlowski wrote: > On Wed, Sep 30, 2020 at 11:17:06AM +0800, Zhen Lei wrote: >> Convert the Hisilicon CPU controller binding to DT schema format using >> json-schema. >> >> Signed-off-by: Zhen Lei >> --- >> .../bindings/arm/hisilicon/controller/cpuctrl.yaml | 29

Re: [PATCH v6 16/17] dt-bindings: arm: hisilicon: convert hisilicon,hi3798cv200-perictrl bindings to json-schema

On 2020/10/1 14:35, Krzysztof Kozlowski wrote: > On Wed, Sep 30, 2020 at 11:17:11AM +0800, Zhen Lei wrote: >> Convert the Hisilicon Hi3798CV200 Peripheral Controller binding to DT >> schema format using json-schema. >> >> Signed-off-by: Zhen Lei >> --- >>

Re: [PATCH v3 2/2] ARM: support PHYS_OFFSET minimum aligned at 64KiB boundary

On 2020/9/16 19:15, Ard Biesheuvel wrote: > (+ Arnd, Nico) > > On Wed, 16 Sep 2020 at 05:51, Zhen Lei wrote: >> >> Currently, only support the kernels where the base of physical memory is >> at a 16MiB boundary. Because the add/sub instructions only contains 8bits >> unrotated value. But we

Re: [PATCH v2 2/2] ARM: support PHYS_OFFSET minimum aligned at 64KiB boundary

On 2020/9/16 15:57, Russell King - ARM Linux admin wrote: > On Wed, Sep 16, 2020 at 09:57:15AM +0800, Leizhen (ThunderTown) wrote: >> On 2020/9/16 3:01, Russell King - ARM Linux admin wrote: >>> On Tue, Sep 15, 2020 at 09:16:15PM +0800, Zhen Lei wrote: >>>> Curre

Re: [PATCH 1/2] dt-bindings: interrupt-controller: add Hisilicon SD5203 vector interrupt controller

On 2020/9/15 14:12, Leizhen (ThunderTown) wrote: > > > On 2020/9/15 4:31, Rob Herring wrote: >> On Thu, Sep 03, 2020 at 08:05:03PM +0800, Zhen Lei wrote: >>> Add DT bindings for the Hisilicon SD5203 vector interrupt controller. >>> >>> Signed-of

Re: [PATCH v4 1/4] genirq: define an empty function set_handle_irq() if !GENERIC_IRQ_MULTI_HANDLER

On 2020/9/15 16:43, Zhen Lei wrote: > To avoid compilation error if an irqchip driver references the function > set_handle_irq() but may not select GENERIC_IRQ_MULTI_HANDLER on some > systems. Hi, Marc: Do you agree with this method? Otherwise, I should use "#ifdef

Re: [PATCH v4 1/4] genirq: define an empty function set_handle_irq() if !GENERIC_IRQ_MULTI_HANDLER

On 2020/9/17 17:32, Marc Zyngier wrote: > On 2020-09-17 04:46, Leizhen (ThunderTown) wrote: >> On 2020/9/15 16:43, Zhen Lei wrote: >>> To avoid compilation error if an irqchip driver references the function >>> set_handle_irq() but may not select GENERIC_IRQ_MULTI_

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

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

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

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

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

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 v2 1/1] samples/seccomp: eliminate two compile warnings in user-trap.c

On 2020/9/9 7:42, Kees Cook wrote: > On Wed, Sep 02, 2020 at 09:33:06AM +0800, Leizhen (ThunderTown) wrote: >> On 2020/9/1 16:39, Zhen Lei wrote: >>> samples/seccomp/user-trap.c is compiled with $(userccflags), and the >>> latter does not contain -fno-strict-aliasin

Re: [PATCH v4 0/1] libnvdimm: fix memory leaks in of_pmem.c

On 2020/9/1 18:14, Markus Elfring wrote: >> v3 --> v4 >> 1. Merge patch 1 and 2 into one: > > How do you think about to omit a cover letter for a single patch? After all, the code hasn't changed except this merge. > > Regards, > Markus > >

Re: [PATCH v2 1/1] samples/seccomp: eliminate two compile warnings in user-trap.c

Doesn't anyone care about this? Or is it that everyone hasn't encountered this problem? Why do these two warnings occur every time I compiled? On 2020/9/1 16:39, Zhen Lei wrote: > samples/seccomp/user-trap.c is compiled with $(userccflags), and the > latter does not contain -fno-strict-aliasing,

Re: [PATCH v4 00/23] device-dax: Support sub-dividing soft-reserved ranges

On 8/22/2020 7:21 AM, Andrew Morton wrote: > On Wed, 19 Aug 2020 18:53:57 -0700 Dan Williams > wrote: > >>> I think I am missing some important pieces. Bear with me. >> >> No worries, also bear with me, I'm going to be offline intermittently >> until at least mid-September. Hopefully Joao

Re: [PATCH v3 2/3] irqchip: dw-apb-ictl: support hierarchy irq domain

On 2020/9/13 23:10, Marc Zyngier wrote: > On Wed, 09 Sep 2020 07:58:35 +0100, > Zhen Lei wrote: >> >> Add support to use dw-apb-ictl as primary interrupt controller. >> >> Suggested-by: Marc Zyngier >> Signed-off-by: Zhen Lei >> Tested-by: Haoyu Lv >> --- >> drivers/irqchip/Kconfig

Re: [PATCH 3/3] ARM: dts: add SD5203 dts

On 2020/9/14 17:29, Wei Xu wrote: > Hi Zhen, > > On 2020/9/3 20:27, Zhen Lei wrote: >> From: Kefeng Wang >> >> Add sd5203.dts for Hisilicon SD5203 SoC platform. >> >> Signed-off-by: Kefeng Wang >> Signed-off-by: Zhen Lei >> --- >> arch/arm/boot/dts/Makefile | 2 + >>

Re: [PATCH v2 0/9] clocksource: sp804: add support for Hisilicon sp804 timer

Hi, Daniel Lezcano, Thomas Gleixner: Do you have time to review these patches? On 2020/9/12 19:45, Zhen Lei wrote: > v1 --> v2: > 1. Split the Patch 3 of v1 into three patches: Patch 3-5 > 2. Change compatible "hisi,sp804" to "hisilicon,sp804" in Patch 7. > 3. Add dt-binding description of

Re: [PATCH 1/2] dt-bindings: interrupt-controller: add Hisilicon SD5203 vector interrupt controller

On 2020/9/15 4:31, Rob Herring wrote: > On Thu, Sep 03, 2020 at 08:05:03PM +0800, Zhen Lei wrote: >> Add DT bindings for the Hisilicon SD5203 vector interrupt controller. >> >> Signed-off-by: Zhen Lei >> --- >> .../hisilicon,sd5203-vic.txt | 27 +++ > >

Re: [PATCH v4 1/1] libnvdimm: fix memory leaks in of_pmem.c

Hi, all: Is this patch acceptable? On 2020/9/1 16:14, Zhen Lei wrote: > Currently, in the last error path of of_pmem_region_probe() and in > of_pmem_region_remove(), free the memory allocated by kstrdup() is > missing. Add kfree(priv->bus_desc.provider_name) to fix it. > > In addition, add a

Re: [PATCH v3 0/9] clocksource: sp804: add support for Hisilicon sp804 timer

On 2020/9/19 19:51, Daniel Lezcano wrote: > On 18/09/2020 15:22, Zhen Lei wrote: > > [ ... ] > >> >> Zhen Lei (8): >> clocksource: sp804: remove unused sp804_timer_disable() and >> timer-sp804.h >> clocksource: sp804: delete the leading "__" of some functions >> clocksource: sp804:

Re: [PATCH v3 9/9] dt-bindings: sp804: add support for Hisilicon sp804 timer

On 2020/9/19 19:43, Daniel Lezcano wrote: > On 18/09/2020 15:22, Zhen Lei wrote: >> Some Hisilicon SoCs, such as Hi1212, use the Hisilicon extended sp804 >> timer. >> >> Signed-off-by: Zhen Lei >> --- > > I'm not able to apply this patch, the file does not exists. Hi Rob Herring: I will

Re: [PATCH v2 2/2] ARM: support PHYS_OFFSET minimum aligned at 64KiB boundary

On 2020/9/17 22:00, Ard Biesheuvel wrote: > On Tue, 15 Sep 2020 at 22:06, Russell King - ARM Linux admin > wrote: >> >> On Tue, Sep 15, 2020 at 09:16:15PM +0800, Zhen Lei wrote: >>> Currently, only support the kernels where the base of physical memory is >>> at a 16MiB boundary. Because the

Re: [PATCH v2 2/2] ARM: support PHYS_OFFSET minimum aligned at 64KiB boundary

On 2020/9/21 14:47, Ard Biesheuvel wrote: > On Mon, 21 Sep 2020 at 05:35, Leizhen (ThunderTown) > wrote: >> >> >> >> On 2020/9/17 22:00, Ard Biesheuvel wrote: >>> On Tue, 15 Sep 2020 at 22:06, Russell King - ARM Linux admin >>> wrote: >>

Re: [PATCH v2 2/2] ARM: support PHYS_OFFSET minimum aligned at 64KiB boundary

On 2020/9/16 3:01, Russell King - ARM Linux admin wrote: > On Tue, Sep 15, 2020 at 09:16:15PM +0800, Zhen Lei wrote: >> Currently, only support the kernels where the base of physical memory is >> at a 16MiB boundary. Because the add/sub instructions only contains 8bits >> unrotated value. But

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

On 2020/12/10 16:24, Manivannan Sadhasivam wrote: > This commit documents the LED triggers used commonly in the SoCs. Not > all triggers are documented as some of them are very application specific. > Most of the triggers documented here are currently used in devicetrees > of many SoCs. > >

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

On 2020/12/13 10:39, Leizhen (ThunderTown) wrote: > > > On 2020/12/10 16:24, Manivannan Sadhasivam wrote: >> This commit documents the LED triggers used commonly in the SoCs. Not >> all triggers are documented as some of them are very application specific. >> Most

Re: [PATCH 1/1] ARM: LPAE: use phys_addr_t instead of unsigned long in outercache hooks

On 2020/12/25 19:44, Zhen Lei wrote: > The outercache of some Hisilicon SOCs support physical addresses wider > than 32-bits. The unsigned long datatype is not sufficient for mapping > physical addresses >= 4GB. The commit ad6b9c9d78b9 ("ARM: 6671/1: LPAE: > use phys_addr_t instead of unsigned

Re: [PATCH v2 1/1] ARM: dts: mmp2-olpc-xo-1-75: clear the warnings when make dtbs

On 2020/12/8 21:58, Arnd Bergmann wrote: > On Mon, Dec 7, 2020 at 9:47 AM Zhen Lei wrote: >> >> The check_spi_bus_bridge() in scripts/dtc/checks.c requires that the node >> have "spi-slave" property must with "#address-cells = <0>" and >> "#size-cells = <0>". But currently both

Re: [RESEND PATCH v3 1/4] iommu/iova: Add free_all_cpu_cached_iovas()

On 2020/11/17 18:25, John Garry wrote: > Add a helper function to free the CPU rcache for all online CPUs. > > There also exists a function of the same name in > drivers/iommu/intel/iommu.c, but the parameters are different, and there > should be no conflict. > > Signed-off-by: John Garry > ---

Re: [RESEND PATCH v3 2/4] iommu/iova: Avoid double-negatives in magazine helpers

On 2020/11/17 18:25, John Garry wrote: > A similar crash to the following could be observed if initial CPU rcache > magazine allocations fail in init_iova_rcaches(): > > Unable to handle kernel NULL pointer dereference at virtual address > > Mem abort info: >ESR =

Re: [RESEND PATCH v3 3/4] iommu/iova: Flush CPU rcache for when a depot fills

On 2020/11/17 18:25, John Garry wrote: > Leizhen reported some time ago that IOVA performance may degrade over time > [0], but unfortunately his solution to fix this problem was not given > attention. > > To summarize, the issue is that as time goes by, the CPU rcache and depot > rcache

Re: [RESEND PATCH v3 3/4] iommu/iova: Flush CPU rcache for when a depot fills

On 2020/12/9 19:22, John Garry wrote: > On 09/12/2020 09:13, Leizhen (ThunderTown) wrote: >> >> >> On 2020/11/17 18:25, John Garry wrote: >>> Leizhen reported some time ago that IOVA performance may degrade over time >>> [0], but unfortunately his sol

Re: [RESEND PATCH v3 2/4] iommu/iova: Avoid double-negatives in magazine helpers

On 2020/12/9 19:39, John Garry wrote: > On 09/12/2020 09:03, Leizhen (ThunderTown) wrote: >> >> >> On 2020/11/17 18:25, John Garry wrote: >>> A similar crash to the following could be observed if initial CPU rcache >>> magazine allocations fail in init_i

Re: [PATCH 1/1] dt-bindings: leds: add onboard LED triggers of 96Boards

On 2020/12/10 11:31, Manivannan Sadhasivam wrote: > Hi, > > On Thu, Dec 10, 2020 at 11:12:03AM +0800, Zhen Lei wrote: >> For all 96Boards, the following standard is used for onboard LEDs. >> >> green:user1 default-trigger: heartbeat >> green:user2 default-trigger:

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

On 2020/12/10 14:14, Manivannan Sadhasivam wrote: > This commit documents the LED triggers used commonly in the SoCs. Not > all triggers are documented as some of them are very application specific. > Most of the triggers documented here are currently used in devicetrees > of many SoCs. > >

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

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

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

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

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 > [..] >

Re: [PATCH 1/1] ARM: LPAE: use phys_addr_t instead of unsigned long in outercache hooks

On 2020/12/26 20:13, Russell King - ARM Linux admin wrote: > On Fri, Dec 25, 2020 at 07:44:58PM +0800, Zhen Lei wrote: >> The outercache of some Hisilicon SOCs support physical addresses wider >> than 32-bits. The unsigned long datatype is not sufficient for mapping >> physical addresses >=

Re: [PATCH 1/1] ARM: LPAE: use phys_addr_t instead of unsigned long in outercache hooks

On 2020/12/26 20:15, Russell King - ARM Linux admin wrote: > On Sat, Dec 26, 2020 at 10:18:08AM +0800, Leizhen (ThunderTown) wrote: >> On 2020/12/25 19:44, Zhen Lei wrote: >>> The outercache of some Hisilicon SOCs support physical addresses wider >>> than 32-bits.

Re: [PATCH 1/1] ARM: LPAE: use phys_addr_t instead of unsigned long in outercache hooks

On 2020/12/28 15:00, Arnd Bergmann wrote: > On Fri, Dec 25, 2020 at 12:48 PM Zhen Lei wrote: >> >> The outercache of some Hisilicon SOCs support physical addresses wider >> than 32-bits. The unsigned long datatype is not sufficient for mapping >> physical addresses >= 4GB. The commit

<    1   2   3   4   5   >