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

[wangyushan <wangyushan12@huawei.com>]

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@huawei.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