linux-kernel - Re: [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <16b06f6f-e251-4fb6-9c82-e9a366351a02@huawei.com>
Date: Thu, 5 Feb 2026 19:30:59 +0800
From: wangyushan <wangyushan12@...wei.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
CC: Arnd Bergmann <arnd@...db.de>, Alexandre Belloni
	<alexandre.belloni@...tlin.com>, Drew Fustini <fustini@...nel.org>, "Jonathan
 Cameron" <Jonathan.Cameron@...wei.com>, Linus Walleij
	<linus.walleij@...aro.org>, Will Deacon <will@...nel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
	<fanghao11@...wei.com>, <linuxarm@...wei.com>, <liuyonglong@...wei.com>,
	<prime.zeng@...ilicon.com>, Zhou Wang <wangzhou1@...ilicon.com>, Wei Xu
	<xuwei5@...ilicon.com>
Subject: Re: [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC

On 2/5/2026 7:23 PM, Krzysztof Kozlowski wrote:
> On 05/02/2026 12:19, wangyushan wrote:
>>
>> On 2/5/2026 5:37 PM, Krzysztof Kozlowski wrote:
>>> On 03/02/2026 18:19, Arnd Bergmann wrote:
>>>> On Tue, Feb 3, 2026, at 17:18, Yushan Wang wrote:
>>>>> The driver will create a file of `/dev/hisi_l3c` on init, mmap
>>>>> operations to it will allocate a memory region that is guaranteed to be
>>>>> placed in L3 cache.
>>>>>
>>>>> The driver also provides unmap() to deallocated the locked memory.
>>>>>
>>>>> The driver also provides an ioctl interface for user to get cache lock
>>>>> information, such as lock restrictions and locked sizes.
>>>>>
>>>>> Signed-off-by: Yushan Wang <wangyushan12@...wei.com>
>>>>
>>>> Hi Yushan,
>>>>
>>>> Thanks for your submission. Since we are in the last week of
>>>> the merge window, this is not going to be linux-7.0 material,
>>>> but I'll have a quick look for now.
>>>
>>>
>>> To be clear - this is a v3 but with removed previous history...
>>>
>>> Previous version:
>>> https://lore.kernel.org/all/20251217102357.1730573-2-wangyushan12@huawei.com/
>>>
>>> Or even v4?
>>>
>>> https://lore.kernel.org/all/20250122065803.3363926-2-wangyushan12@huawei.com/
>>>
>>> Yushan, please start versioning your patches correctly. Use b4 or git
>>> format-patch -vx
>>
>> Hi Krzysztof,
>>
>> Sorry about the confusing versions, the complete history is as below:
>>
>> Link to v1: https://lore.kernel.org/all/20250107132907.3521574-1-wangyushan12@huawei.com
>>
>> Link to v2: https://lore.kernel.org/all/20250122065803.3363926-1-wangyushan12@huawei.com/
>>
>> Link to RFC v1: https://lore.kernel.org/all/20251125080542.3721829-1-wangyushan12@huawei.com/
>>
>> Link to RFC v2: https://lore.kernel.org/all/20251217102357.1730573-1-wangyushan12@huawei.com/
>>
>> Link to v1 again (this message): https://lore.kernel.org/all/20260203161843.649417-1-wangyushan12@huawei.com/
>>
>>>
>>> Otherwise, please explain us how can we compare it with `b4 diff` with
>>> previous version?
>>>
>>> Sending something AGAIN as v1 ignoring entire previous submission is
>>> clear no go. Like you are trying till it succeeds. Negative review?
>>> Let's try from v1 this time...
>>>
>>> This is not correct and it should not be my task to find your previous
>>> discussions and decipher this v1.
>>
>> I did spin 2 versions to mainline as the actual v1, the thread was quiet.
>> Then I made a major refactor to it and sent it as RFC, the thread went
>> quiet again but some compile check issues popped up. I spinned 2
>> versions of RFC for the compile issues and removed RFC in this version
>> since no strong objection showed up.
>>
>> Apologize that I broke the rules and any inconvenience caused by it.
>> As there's little discussion in previous patches, is it OK that we start
>> here as v1?
>
> No, it is not okay. Your patchset continues and entire previous feedback
> and history is important. Otherwise why would I review this if I can as
> well ignore it and wait for next year you sending another v1?

Sorry, I will correct the version numbers in next versions, with whole
history and explanations about the mess.

Sincerely apologies, I won't hide the versions again.

Yushan