On 2016/7/12 23:35, Catalin Marinas wrote:
> On Mon, Jul 11, 2016 at 08:43:32PM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/7/9 0:13, Catalin Marinas wrote:
>>> On Fri, Jul 08, 2016 at 11:24:26PM +0800, Leizhen (ThunderTown) wrote:
>>>> On 2016/7/
On 2016/9/19 22:45, Will Deacon wrote:
> On Mon, Sep 19, 2016 at 03:07:19PM +0100, Mark Rutland wrote:
>> [adding LAKML, arm64 maintainers]
>
> I've also looped in Euler ThunderTown, since (a) he's at Huawei and is
> assumedly testing this stuff and (b) he has a fairly big NUMA patch
> series do
On 2016/6/14 22:22, Catalin Marinas wrote:
> On Wed, Jun 08, 2016 at 04:59:03PM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/6/7 21:58, Will Deacon wrote:
>>> On Tue, Jun 07, 2016 at 04:08:04PM +0800, Zhen Lei wrote:
>>>> v3 -> v4:
>>>> 1. Packed t
On 2016/6/20 14:39, Leizhen (ThunderTown) wrote:
>
>
> On 2016/6/14 22:22, Catalin Marinas wrote:
>> On Wed, Jun 08, 2016 at 04:59:03PM +0800, Leizhen (ThunderTown) wrote:
>>> On 2016/6/7 21:58, Will Deacon wrote:
>>>> On Tue, Jun 07, 2016 at 04:08:04PM +
On 2016/9/8 19:01, Will Deacon wrote:
> On Thu, Sep 01, 2016 at 02:54:51PM +0800, Zhen Lei wrote:
>> v7 -> v8:
>> Updated patches according to Will Deacon's review comments, thanks.
>>
>> The changed patches is: 3, 5, 8, 9, 10, 11, 12, 13, 15
>> Patch 3 requires an ack from Rob Herring.
>> Patch
Hi, linux-mm folks:
Can somebody help me to review this patch?
I ran scripts/get_maintainer.pl -f mm/memblock.c and
scripts/get_maintainer.pl -f mm/, but
the results showed me that there is no maintainer.
To understand this patch should also read patch 11.
On 2016/9/1 14:55, Zhen Lei
On 2016/8/31 1:51, Will Deacon wrote:
> On Sat, Aug 27, 2016 at 04:54:56PM +0800, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2016/8/26 20:47, Will Deacon wrote:
>>> On Wed, Aug 24, 2016 at 03:44:44PM +0800, Zhen Lei wrote:
>>>> numa_init(of_num
On 2016/8/31 1:55, Will Deacon wrote:
> On Sat, Aug 27, 2016 at 06:44:39PM +0800, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2016/8/26 23:35, Will Deacon wrote:
>>> On Wed, Aug 24, 2016 at 03:44:53PM +0800, Zhen Lei wrote:
>>>> Update documentation. This l
On 2016/8/24 1:28, Catalin Marinas wrote:
> On Mon, Aug 22, 2016 at 12:19:04PM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/7/20 17:19, Catalin Marinas wrote:
>>> On Wed, Jul 20, 2016 at 10:46:27AM +0800, Leizhen (ThunderTown) wrote:
>>>>>>>>
On 2016/8/24 1:28, Catalin Marinas wrote:
> On Mon, Aug 22, 2016 at 12:19:04PM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/7/20 17:19, Catalin Marinas wrote:
>>> On Wed, Jul 20, 2016 at 10:46:27AM +0800, Leizhen (ThunderTown) wrote:
>>>>>>>>
On 2016/8/24 18:30, Catalin Marinas wrote:
> On Wed, Aug 24, 2016 at 05:00:50PM +0800, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2016/8/24 1:28, Catalin Marinas wrote:
>>> On Mon, Aug 22, 2016 at 12:19:04PM +0800, Leizhen (ThunderTown) wrote:
>>>>
On 2016/8/25 17:30, Catalin Marinas wrote:
> On Thu, Aug 25, 2016 at 09:42:26AM +0800, Leizhen (ThunderTown) wrote:
>> On 2016/8/24 18:30, Catalin Marinas wrote:
>>>>>>>>>>>> On 2016/7/8 21:54, Catalin Marinas wrote:
>>>>>>>>
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 dir
On 2017/6/20 19:35, Robin Murphy wrote:
> On 20/06/17 12:04, Zhen Lei wrote:
>> This function is protected by spinlock, and the latter will do memory
>> barrier implicitly. So that we can safely use writel_relaxed. In fact, the
>> dmb operation will lengthen the time protected by lock, which indi
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, and
On 2017/10/18 21:00, Will Deacon wrote:
> On Tue, Sep 12, 2017 at 09:00:37PM +0800, Zhen Lei wrote:
>> This patch is base on:
>> (add02cfdc9bc2 "iommu: Introduce Interface for IOMMU TLB Flushing")
>>
>> Because iotlb_sync is moved out of ".unmap = arm_smmu_unmap", some interval
>> ".unmap" calls
On 2015/9/28 17:44, Leizhen (ThunderTown) wrote:
>> >
>>> >> --drivers/char/Kconfig--
>>> >> if RTC_LIB=n
>>> >>
>>> >> config RTC
>>> >> tristate "Enhanced Real Time
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 +
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 ++
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 MSI
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 sta
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 regist
On 2024/7/31 9:00, Song Liu wrote:
> Hi Masami,
>
>> On Jul 30, 2024, at 6:03 AM, Masami Hiramatsu wrote:
>>
>> On Mon, 29 Jul 2024 17:54:32 -0700
>> Song Liu wrote:
>>
>>> With CONFIG_LTO_CLANG=y, the compiler may add suffix to function names
>>> to avoid duplication. This causes confusion
On 2024/8/2 11:45, Song Liu wrote:
>
>
>> On Aug 1, 2024, at 6:18 PM, Leizhen (ThunderTown)
>> wrote:
>>
>> On 2024/7/31 9:00, Song Liu wrote:
>>> Hi Masami,
>>>
>>>> On Jul 30, 2024, at 6:03 AM, Masami Hiramatsu wrote:
>&
On 2024/8/20 22:30, Oleg Nesterov wrote:
> On 08/20, Zhen Lei wrote:
>>
>> Depending on the argument 'add', uprobe_apply() may be registering or
>> unregistering a probe.
>
> ...
>
>> /*
>> - * uprobe_apply - unregister an already registered probe.
>> - * @inode: the file in which the probe h
On 2024/9/10 2:41, Thomas Gleixner wrote:
> On Wed, Sep 04 2024 at 21:41, Zhen Lei wrote:
>
>> Currently, there are multiple instances where several nodes are extracted
>> from one list and added to another list. One by one extraction, and then
>> one by one splicing, not only low efficiency, r
On 2024/9/10 19:44, Thomas Gleixner wrote:
> On Tue, Sep 10 2024 at 12:00, Leizhen wrote:
>> On 2024/9/10 2:41, Thomas Gleixner wrote:
>>> All related functions have this problem and all of this code is very
>>> strict about boundaries. Instead of accurately doing the refill, purge
>>> etc. we s
On 2024/9/11 16:54, Thomas Gleixner wrote:
> On Wed, Sep 11 2024 at 15:44, Leizhen wrote:
>> On 2024/9/10 19:44, Thomas Gleixner wrote:
>>> That minimizes the pool lock contention and the cache foot print. The
>>> global to free pool must have an extra twist to accomodate non-batch
>>> sized dro
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
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
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
SIGINFO)
? &restore_rt : &restore);
}
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
>&
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
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?
>>
>>
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)
>>>
On 2019/2/26 20:36, Hanjun Guo wrote:
> Hi Jean,
>
> On 2019/1/31 22:55, Jean-Philippe Brucker wrote:
>> Hi,
>>
>> On 31/01/2019 13:52, Zhen Lei wrote:
>>> Currently, many peripherals are faster than before. For example, the top
>>> speed of the older netcard is 10Gb/s, and now it's more than 2
It seems that the picture is too big, I change it from jpg to png.
On 2019/3/1 17:02, Leizhen (ThunderTown) wrote:
> Hi All,
> I drew a flowchart, hope this can help you to understand my method.
>
> On 2019/2/19 15:54, Zhen Lei wrote:
>> To reduce the risk of
On 2019/3/1 19:07, Jean-Philippe Brucker wrote:
> Hi Leizhen,
>
> On 01/03/2019 04:44, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2019/2/26 20:36, Hanjun Guo wrote:
>>> Hi Jean,
>>>
>>> On 2019/1/31 22:55, Jean-Philippe Brucker wrote:
Hi Will, Robin:
Do you have time to review these patches? Hope you can give me some opinions.
On 2019/2/19 15:54, Zhen Lei wrote:
> This patch series include two parts:
> 1. Patch1-2 use dummy STE tables with "ste abort" hardware feature to abort
> unexpected
>devices accessing. For more
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 + L3_MAINT_
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 execu
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 addre
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
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 address
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:
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 agai
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, b
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 merged
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 reser
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
>>
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 sl
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 info
On 8/19/2020 3:00 AM, Markus Elfring wrote:
>> The memory priv->bus_desc.provider_name allocated by kstrdup() should be
>> freed.
>
> * Would an imperative wording be preferred for the change description?
>
> * I propose to add the tag “Fixes” to the commit message.
Thanks for your suggestion,
On 8/19/2020 8:20 PM, Markus Elfring wrote:
>> v1 --> v2:
>> 1. Add Fixes for Patch 1-2
>> 2. Slightly change the subject and description of Patch 1
> …
>> libnvdimm: fix memmory leaks in of_pmem.c
> …
>
> I suggest to avoid a typo in such a patch subject.
OK, Thanks for reminding me.
>
>
On 8/19/2020 8:28 PM, Markus Elfring wrote:
>> The memory priv->bus_desc.provider_name allocated by kstrdup() is not
>> freed correctly.
>
> How do you think about to choose an imperative wording for
> a corresponding change description?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvald
On 8/19/2020 8:40 PM, Markus Elfring wrote:
>> … when is_nvdimm_bus(dev) successed.
>
> I imagine that that an other wording will be more appropriate here.
OK, I will rewrite it.
>
> Regards,
> Markus
>
>
On 8/19/2020 9:35 PM, Oliver O'Halloran wrote:
> On Wed, Aug 19, 2020 at 10:28 PM Markus Elfring wrote:
>>
>>> The memory priv->bus_desc.provider_name allocated by kstrdup() is not
>>> freed correctly.
>
> Personally I thought his commit message was perfectly fine. A little
> unorthodox, but i
On 8/19/2020 9:37 PM, Oliver O'Halloran wrote:
> On Wed, Aug 19, 2020 at 12:05 PM Zhen Lei wrote:
>>
>> The memory priv->bus_desc.provider_name allocated by kstrdup() is not
>> freed correctly.
>>
>> Fixes: 49bddc73d15c ("libnvdimm/of_pmem: Provide a unique name for bus
>> provider")
>> Signed
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 fixed
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
>> +
>> +maintainers:
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.
>
> Whi
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
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: elimi
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
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
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: 35
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
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
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
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 ARM_SMMU_
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 2010
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 >= 4GB.
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. Th
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 ad6b9c9d78
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
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 >= 4GB.
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 l
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:
>
> https://patchwork.kernel.org/project/linux-watchdog/patch/20210325112916.865510-1-wa
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 a
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'
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 assign
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 /s/appropriatley/ap
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 "alignement"
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. I
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 th
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
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 changed,
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 change t
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 fi
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 "#address-cells"
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
> ---
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 = 0x96
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 continu
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
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
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: mmc0/disk-activity(onboard-s
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.
>
> Sig
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:
>
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 i
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, sorry
1 - 100 of 305 matches
Mail list logo
