| 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
| ||
|
Message-ID: <82c73122-4d0e-45f5-b1b4-3cf743353fd6@kernel.org> Date: Thu, 5 Feb 2026 12:23:28 +0100 From: Krzysztof Kozlowski <krzk@...nel.org> To: wangyushan <wangyushan12@...wei.com> 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 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? Best regards, Krzysztof
Powered by blists - more mailing lists