Re: [PATCH 0/8] iommu: fix a couple of spelling mistakes detected by codespell tool

2021-04-16 Thread Leizhen (ThunderTown)
On 2021/4/16 23:24, Joerg Roedel wrote: > On Fri, Mar 26, 2021 at 02:24:04PM +0800, Zhen Lei wrote: >> This detection and correction covers the entire driver/iommu directory. >> >> Zhen Lei (8): >> iommu/pamu: fix a couple of spelling mistakes >> iommu/omap: Fix spelling mistake

Re: [PATCH 5/8] iommu: fix a couple of spelling mistakes

2021-04-16 Thread Leizhen (ThunderTown)
On 2021/4/16 23:55, John Garry wrote: > On 26/03/2021 06:24, Zhen Lei wrote: >> There are several spelling mistakes, as follows: >> funcions ==> functions >> distiguish ==> distinguish >> detroyed ==> destroyed >> >> Signed-off-by: Zhen Lei > > I think that there should be a

Re: [PATCH 1/1] char: hpet: Remove unused local variable 'm' in hpet_interrupt()

2021-04-15 Thread Leizhen (ThunderTown)
On 2021/4/15 22:53, Greg Kroah-Hartman wrote: > On Thu, Apr 15, 2021 at 10:24:04PM +0800, Zhen Lei wrote: >> Commit 273ef9509b79 ("drivers/char/hpet.c: fix periodic-emulation for >> delayed interrupt") removed the reference to local variable 'm', but >> forgot to remove the definition and

Re: [PATCH 1/1] perf map: Fix error return code in maps__clone()

2021-04-15 Thread Leizhen (ThunderTown)
On 2021/4/15 20:42, Arnaldo Carvalho de Melo wrote: > Em Thu, Apr 15, 2021 at 05:27:44PM +0800, Zhen Lei escreveu: >> Although 'err' has been initialized to -ENOMEM, but it will be reassigned >> by the "err = unwind__prepare_access(...)" statement in the for loop. So >> that, the value of 'err'

Re: [PATCH 0/3] scsi: mptfusion: Clear the warnings indicating that the variable is not used

2021-04-13 Thread Leizhen (ThunderTown)
On 2021/4/13 13:07, Martin K. Petersen wrote: > > Zhen, > >> Zhen Lei (3): >> scsi: mptfusion: Remove unused local variable 'time_count' >> scsi: mptfusion: Remove unused local variable 'port' >> scsi: mptfusion: Fix error return code of mptctl_hp_hostinfo() > > I applied patches 1+2.

Re: [PATCH v2 2/2] ASoC: dt-bindings: renesas, rsnd: Clear warning 'ports' does not match any of the regexes

2021-04-12 Thread Leizhen (ThunderTown)
On 2021/4/9 4:42, Rob Herring wrote: > On Thu, Apr 08, 2021 at 08:28:08PM +0800, Leizhen (ThunderTown) wrote: >> >> >> On 2021/4/7 10:04, Leizhen (ThunderTown) wrote: >>> >>> >>> On 2021/4/2 4:20, Rob Herring wrote: >>>> On Wed, Mar 3

Re: [PATCH v2 2/2] ASoC: dt-bindings: renesas, rsnd: Clear warning 'ports' does not match any of the regexes

2021-04-08 Thread Leizhen (ThunderTown)
On 2021/4/7 10:04, Leizhen (ThunderTown) wrote: > > > On 2021/4/2 4:20, Rob Herring wrote: >> On Wed, Mar 31, 2021 at 05:16:16PM +0800, Zhen Lei wrote: >>> Currently, if there are more than two ports, or if there is only one port >>> but other properties(such

Re: [PATCH v2 2/2] ASoC: dt-bindings: renesas, rsnd: Clear warning 'ports' does not match any of the regexes

2021-04-06 Thread Leizhen (ThunderTown)
On 2021/4/2 4:20, Rob Herring wrote: > On Wed, Mar 31, 2021 at 05:16:16PM +0800, Zhen Lei wrote: >> Currently, if there are more than two ports, or if there is only one port >> but other properties(such as "#address-cells") is required, these ports >> are placed under the "ports" node. So add

Re: [PATCH 1/2] ASoC: dt-bindings: renesas, rsnd: Clear warning 'dais' is a required property

2021-03-30 Thread Leizhen (ThunderTown)
On 2021/3/31 6:45, Rob Herring wrote: > On Tue, Mar 30, 2021 at 11:06:30AM +0800, Zhen Lei wrote: >> When I do dt_binding_check, below warning is reported: >> Documentation/devicetree/bindings/sound/renesas,rsnd.example.dt.yaml: \ >> sound@ec50: 'dais' is a required property >> >> I looked

Re: [PATCH 1/1] watchdog: dw_wdt: Remove duplicated header file inclusion

2021-03-30 Thread Leizhen (ThunderTown)
On 2021/3/28 3:50, Guenter Roeck wrote: > On 3/26/21 6:20 PM, Zhen Lei wrote: >> The header file is already included above and can be >> removed here. >> >> Signed-off-by: Zhen Lei > > Already submitted: > >

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

2021-02-02 Thread Leizhen (ThunderTown)
On 2021/2/2 16:44, Arnd Bergmann wrote: > On Tue, Feb 2, 2021 at 8:16 AM Zhen Lei wrote: >> + >> +/* >> + * All read and write operations on L3 cache registers are protected by the >> + * spinlock, except for l3cache_init(). Each time the L3 cache operation is >> + * performed, all related

Re: [PATCH v5 0/1] perf/smmuv3: Don't reserve the PMCG register spaces

2021-02-01 Thread Leizhen (ThunderTown)
On 2021/2/1 23:50, Will Deacon wrote: > On Mon, Feb 01, 2021 at 09:27:49PM +0800, Zhen Lei wrote: >> v4 --> v5: >> 1. Give up doing the mapping for the entire SMMU register space. >> 2. Fix some compile warnings. Sorry. So sorry. > > That's alright, these things happen. However, this came in

Re: [PATCH v4 1/2] perf/smmuv3: Don't reserve the PMCG register spaces

2021-02-01 Thread Leizhen (ThunderTown)
On 2021/2/1 20:54, Will Deacon wrote: > On Sat, Jan 30, 2021 at 03:14:13PM +0800, Zhen Lei wrote: >> According to the SMMUv3 specification: >> Each PMCG counter group is represented by one 4KB page (Page 0) with one >> optional additional 4KB page (Page 1), both of which are at IMPLEMENTATION

Re: [PATCH v3 3/3] iommu/arm-smmu-v3: Reserving the entire SMMU register space

2021-02-01 Thread Leizhen (ThunderTown)
On 2021/2/1 19:44, Robin Murphy wrote: > On 2021-01-30 01:54, Leizhen (ThunderTown) wrote: >> >> >> On 2021/1/29 23:27, Robin Murphy wrote: >>> On 2021-01-27 11:32, Zhen Lei wrote: >>>> commit 52f3fab0067d ("iommu/arm-smmu-v3: Don't reserve im

Re: [PATCH v6 2/4] ARM: hisi: add support for Kunpeng50x SoC

2021-02-01 Thread Leizhen (ThunderTown)
On 2021/2/1 16:35, Arnd Bergmann wrote: > On Mon, Feb 1, 2021 at 4:35 AM Zhen Lei wrote: >> >> Enable support for the Hisilicon Kunpeng506 and Kunpeng509 SoC. >> >> Signed-off-by: Zhen Lei > > Reviewed-by: Arnd Bergmann > > Russell, do you have a preference for how to get this series

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

2021-02-01 Thread Leizhen (ThunderTown)
On 2021/2/1 16:31, Arnd Bergmann wrote: > On Mon, Feb 1, 2021 at 4:36 AM Zhen Lei wrote: >> >> Add support for the Hisilicon Kunpeng L3 cache controller as used with >> Kunpeng506 and Kunpeng509 SoCs. >> >> These Hisilicon SoCs support LPAE, so the physical addresses is wider than >> 32-bits,

Re: [PATCH v3 3/3] iommu/arm-smmu-v3: Reserving the entire SMMU register space

2021-01-30 Thread Leizhen (ThunderTown)
On 2021/1/29 23:27, Robin Murphy wrote: > On 2021-01-27 11:32, Zhen Lei wrote: >> commit 52f3fab0067d ("iommu/arm-smmu-v3: Don't reserve implementation >> defined register space") only reserves the basic SMMU register space. So >> the ECMDQ register space is not covered, it should be mapped

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

2021-01-30 Thread Leizhen (ThunderTown)
On 2021/1/29 21:54, Leizhen (ThunderTown) wrote: > > > On 2021/1/29 18:26, Arnd Bergmann wrote: >> On Fri, Jan 29, 2021 at 9:16 AM Arnd Bergmann wrote: >>> On Fri, Jan 29, 2021 at 8:23 AM Leizhen (ThunderTown) >>> wrote: >>>> On 2021/1/28 22:

Re: [PATCH v4 1/2] perf/smmuv3: Don't reserve the PMCG register spaces

2021-01-30 Thread Leizhen (ThunderTown)
Hi, Robin: Can you review this patch again? On 2021/1/30 15:14, Zhen Lei wrote: > According to the SMMUv3 specification: > Each PMCG counter group is represented by one 4KB page (Page 0) with one > optional additional 4KB page (Page 1), both of which are at IMPLEMENTATION > DEFINED base

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

2021-01-30 Thread Leizhen (ThunderTown)
On 2021/1/29 18:33, Russell King - ARM Linux admin wrote: > On Fri, Jan 29, 2021 at 11:26:38AM +0100, Arnd Bergmann wrote: >> Another clarification, as there are actually two independent >> points here: >> >> * if you can completely remove the readl() above and just write a >> hardcoded value

Re: [PATCH v3 1/3] perf/smmuv3: Don't reserve the PMCG register spaces

2021-01-29 Thread Leizhen (ThunderTown)
On 2021/1/29 23:06, Robin Murphy wrote: > On 2021-01-27 11:32, Zhen Lei wrote: >> According to the SMMUv3 specification: >> Each PMCG counter group is represented by one 4KB page (Page 0) with one >> optional additional 4KB page (Page 1), both of which are at IMPLEMENTATION >> DEFINED base

Re: [PATCH v3 2/3] perf/smmuv3: Add a MODULE_SOFTDEP() to indicate dependency on SMMU

2021-01-29 Thread Leizhen (ThunderTown)
On 2021/1/30 1:03, Robin Murphy wrote: > On 2021-01-29 15:34, John Garry wrote: >> On 29/01/2021 15:12, Robin Murphy wrote: >>> On 2021-01-27 11:32, Zhen Lei wrote: The MODULE_SOFTDEP() gives user space a hint of the loading sequence. And when command "modprobe arm_smmuv3_pmu" is

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

2021-01-28 Thread Leizhen (ThunderTown)
On 2021/1/28 22:24, Arnd Bergmann wrote: > On Sat, Jan 16, 2021 at 4:27 AM Zhen Lei wrote: >> diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile >> + >> +static void l3cache_maint_common(u32 range, u32 op_type) >> +{ >> + u32 reg; >> + >> + reg = readl(l3_ctrl_base +

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

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

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

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:

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

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

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

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 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 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 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-19 Thread Leizhen (ThunderTown)
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: [v2] Old platforms: bring out your dead

2021-01-15 Thread Leizhen (ThunderTown)
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

2021-01-13 Thread Leizhen (ThunderTown)
On 2021/1/13 19:15, Arnd Bergmann wrote: > On Wed, Jan 13, 2021 at 9:13 AM Leizhen (ThunderTown) > wrote: >> 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

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

2021-01-13 Thread Leizhen (ThunderTown)
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 v3 2/3] dt-bindings: arm: hisilicon: Add binding for L3 cache controller

2021-01-12 Thread Leizhen (ThunderTown)
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

2021-01-12 Thread Leizhen (ThunderTown)
On 2021/1/12 16:46, Arnd Bergmann wrote: > On Tue, Jan 12, 2021 at 2:56 AM Zhen Lei wrote: > >> +--- >> +$id: http://devicetree.org/schemas/arm/hisilicon/l3cache.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Hisilicon L3 cache controller >> + >>

Re: [PATCH 1/1] spi: cadence-quadspi: Fix a compilation warning for 64-bit platform

2021-01-12 Thread Leizhen (ThunderTown)
On 2021/1/12 18:16, Pratyush Yadav wrote: > Hi Zhen, > > On 12/01/21 06:06PM, Zhen Lei wrote: >> The __typecheck() requires that the two arguments of max() must be of the >> same type. For the current max(), the type of the first parameter "len" is >> size_t. But the type of size_t is not

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

2020-12-30 Thread Leizhen (ThunderTown)
On 2020/12/30 17:54, Russell King - ARM Linux admin wrote: > On Wed, Dec 30, 2020 at 04:28:05PM +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

2020-12-30 Thread Leizhen (ThunderTown)
On 2020/12/29 18:51, Russell King - ARM Linux admin wrote: > On Tue, Dec 29, 2020 at 02:30:56PM +0800, Leizhen (ThunderTown) wrote: >> >> >> On 2020/12/26 20:13, Russell King - ARM Linux admin wrote: >>> On Fri, Dec 25, 2020 at 07:44:58PM +0800, Zhen Lei wrot

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

2020-12-28 Thread Leizhen (ThunderTown)
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

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

2020-12-28 Thread Leizhen (ThunderTown)
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

2020-12-28 Thread Leizhen (ThunderTown)
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

2020-12-25 Thread Leizhen (ThunderTown)
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] 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 > [..] >

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

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

2020-12-12 Thread Leizhen (ThunderTown)
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 v2] dt-bindings: leds: Document commonly used LED triggers

2020-12-12 Thread Leizhen (ThunderTown)
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] dt-bindings: leds: Document commonly used LED triggers

2020-12-09 Thread Leizhen (ThunderTown)
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] dt-bindings: leds: add onboard LED triggers of 96Boards

2020-12-09 Thread Leizhen (ThunderTown)
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: [RESEND PATCH v3 2/4] iommu/iova: Avoid double-negatives in magazine helpers

2020-12-09 Thread Leizhen (ThunderTown)
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: [RESEND PATCH v3 3/4] iommu/iova: Flush CPU rcache for when a depot fills

2020-12-09 Thread Leizhen (ThunderTown)
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 3/4] iommu/iova: Flush CPU rcache for when a depot fills

2020-12-09 Thread Leizhen (ThunderTown)
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 2/4] iommu/iova: Avoid double-negatives in magazine helpers

2020-12-09 Thread Leizhen (ThunderTown)
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 1/4] iommu/iova: Add free_all_cpu_cached_iovas()

2020-12-09 Thread Leizhen (ThunderTown)
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: [PATCH v2 1/1] ARM: dts: mmp2-olpc-xo-1-75: clear the warnings when make dtbs

2020-12-08 Thread Leizhen (ThunderTown)
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: [PATCH v2 1/3] reset: hisilicon: correct vendor prefix

2020-12-08 Thread Leizhen (ThunderTown)
On 2020/12/8 17:25, Philipp Zabel wrote: > Hi Zhen, > > On Fri, 2020-12-04 at 09:42 +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") >> Fixes:

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

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

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:

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

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

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

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/2] xfs: check the return value of krealloc()

2020-11-24 Thread Leizhen (ThunderTown)
On 2020/11/24 19:51, Christoph Hellwig wrote: > On Tue, Nov 24, 2020 at 06:45:30PM +0800, Zhen Lei wrote: >> krealloc() may fail to expand the memory space. Add sanity checks to it, >> and WARN() if that really happened. > > What part of the __GFP_NOFAIL semantics isn't clear enough? Oh,

Re: [PATCH 1/1] device-dax: delete a redundancy check in dev_dax_validate_align()

2020-11-20 Thread Leizhen (ThunderTown)
On 2020/11/20 17:20, Zhen Lei wrote: > After we have done the alignment check for the length of each range, the > alignment check for dev_dax_size(dev_dax) is no longer needed, because it > get the sum of the length of each range. For example: x/M + y/M = (x + y)/M If x/M is a integer and y/M

Re: [PATCH 1/1] block: move the PAGE_SECTORS definition into

2020-11-19 Thread Leizhen (ThunderTown)
k. Did this change progress forward somewhere? Actually, I'm trying to make further replacements after this patch is applied. But there was no response except Coly Li. > > Thanks! > > John Dorminy > > > On Mon, Sep 7, 2020 at 3:40 AM Leizhen (ThunderTown) > wrote: >>

Re: [PATCH 1/1] ACPI/nfit: correct the badrange to be reported in nfit_handle_mce()

2020-11-18 Thread Leizhen (ThunderTown)
On 2020/11/19 4:50, Verma, Vishal L wrote: > On Wed, 2020-11-18 at 16:41 +0800, Zhen Lei wrote: >> The badrange to be reported should always cover mce->addr. >> >> Signed-off-by: Zhen Lei >> --- >> drivers/acpi/nfit/mce.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > Ah good

Re: [PATCH 1/1] ACPI/nfit: correct the badrange to be reported in nfit_handle_mce()

2020-11-18 Thread Leizhen (ThunderTown)
On 2020/11/19 3:16, Dan Williams wrote: > On Wed, Nov 18, 2020 at 12:55 AM Leizhen (ThunderTown) > wrote: >> >> >> >> On 2020/11/18 16:41, Zhen Lei wrote: >>> The badrange to be reported should always cover mce->addr. >> Maybe I should chang

Re: [PATCH 1/1] ACPI/nfit: correct the badrange to be reported in nfit_handle_mce()

2020-11-18 Thread Leizhen (ThunderTown)
On 2020/11/18 16:41, Zhen Lei wrote: > The badrange to be reported should always cover mce->addr. Maybe I should change this description to: Make sure the badrange to be reported can always cover mce->addr. > > Signed-off-by: Zhen Lei > --- > drivers/acpi/nfit/mce.c | 2 +- > 1 file

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

2020-11-08 Thread Leizhen (ThunderTown)
t its #address-cells (1) differs from / (2) arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi:7.3-14: Warning (dma_ranges_format): /usb:dma-ranges: empty "dma-ranges" property but its #size-cells (1) differs from / (2) On 2020/10/26 10:21, Leizhen (ThunderTown) wrote: > >

Re: [PATCH 1/1] x86/mce: remove unused WARN_ON() in mce_register_decode_chain()

2020-11-06 Thread Leizhen (ThunderTown)
On 2020/11/6 19:12, Borislav Petkov wrote: > On Fri, Nov 06, 2020 at 04:43:40PM +0800, Zhen Lei wrote: >> enum mce_notifier_prios { >> MCE_PRIO_LOWEST, >> MCE_PRIO_MCELOG, >> MCE_PRIO_EDAC, >> >> After commit c9c6d216ed28 ("x86/mce: Rename "first" function as "early""),

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

2020-10-25 Thread Leizhen (ThunderTown)
On 2020/10/23 15:17, Arnd Bergmann wrote: > On Sun, Oct 18, 2020 at 4:10 AM Leizhen (ThunderTown) > wrote: >> 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 >

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 1/2] arm64: dts: broadcom: remove an unused property dma-ranges

2020-10-16 Thread Leizhen (ThunderTown)
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 1/2] arm64: dts: broadcom: remove an unused property dma-ranges

2020-10-16 Thread Leizhen (ThunderTown)
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 5/6] ARM: dts: mmp2-olpc-xo-1-75: explicitly add #address-cells=<0> for slave mode

2020-10-15 Thread Leizhen (ThunderTown)
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 v2 1/1] dt-bindings: misc: add support for both property names cmd-gpios and cmd-gpio

2020-10-15 Thread Leizhen (ThunderTown)
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 6/6] dt-bindings: misc: correct the property name cmd-gpios to cmd-gpio

2020-10-15 Thread Leizhen (ThunderTown)
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 2/6] dt-bindings: mfd: google,cros-ec: explicitly allow additional properties

2020-10-15 Thread Leizhen (ThunderTown)
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

2020-10-14 Thread Leizhen (ThunderTown)
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 1/2] arm64: dts: broadcom: remove an unused property dma-ranges

2020-10-14 Thread Leizhen (ThunderTown)
On 2020/10/14 21:36, 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 PM, Zhen Lei wrote: >>>> stingray-usb.dtsi is finally included b

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

2020-10-14 Thread Leizhen (ThunderTown)
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 PM, Zhen Lei wrote: >>> stingray-usb.dtsi is finally included by three dts files: >>> bcm958802a802x.dts, bcm958742k.dts and bcm958742t.dts. I searched all >>> these three

Re: [PATCH] dt-bindings: leds: Update devicetree documents for ID_RGB

2020-10-14 Thread Leizhen (ThunderTown)
On 2020/10/14 1:50, Dan Murphy wrote: > Update the leds/common.yaml to indicate that the max color ID is 9. > Reflect the same change in the leds-class-multicolor.yaml > > Reported-by: Zhen Lei > Signed-off-by: Dan Murphy > --- > Documentation/devicetree/bindings/leds/common.yaml | 2

Re: [PATCH 1/1] watchdog: remove unneeded inclusion of

2020-10-13 Thread Leizhen (ThunderTown)
On 2020/9/8 11:34, Leizhen (ThunderTown) wrote: > > > On 2020/9/8 10:40, Guenter Roeck wrote: >> On 9/7/20 12:50 AM, Leizhen (ThunderTown) wrote: >>> Hi, Wim Van Sebroeck, Guenter Roeck: >>> What's your opinion? Guenter Roeck given "Reviewed-by"

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

2020-10-13 Thread Leizhen (ThunderTown)
On 2020/10/14 1:53, Dan Murphy wrote: > Zhen > > On 10/13/20 11:08 AM, 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, extcon-usbc-cros-ec.yaml

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

2020-10-13 Thread Leizhen (ThunderTown)
On 2020/10/14 1:32, Dan Murphy wrote: > Zhen > > On 10/13/20 11:08 AM, 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>; >> >> Signed-off-by: Zhen Lei

Re: [PATCH 1/6] dt-bindings: leds: choose correct color value of multi-led

2020-10-13 Thread Leizhen (ThunderTown)
On 2020/10/14 0:17, Dan Murphy wrote: > Zhen > > On 10/13/20 11:08 AM, Zhen Lei wrote: >> The color value of multi-led is fixed to "const: 8 #LED_COLOR_ID_MULTI", >> which is required by leds-class-multicolor.yaml. >> >> Signed-off-by: Zhen Lei >> --- >>  

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

2020-10-10 Thread Leizhen (ThunderTown)
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 >> --- >>

  1   2   3   4   5   >