Received-SPF: pass (google.com: domain of linux-kernel+bounces-100200-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <65F04374.20308@hisilicon.com>
Date: Tue, 12 Mar 2024 19:58:44 +0800
From: Wei Xu <xuwei5@hisilicon.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
Precedence: bulk
MIME-Version: 1.0
To: Yang Xiwen <forbidden405@outlook.com>, Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley
	<conor+dt@kernel.org>, Jiancheng Xue <xuejiancheng@hisilicon.com>, Alex Elder
	<elder@linaro.org>, Peter Griffin <peter.griffin@linaro.org>
CC: <linux-arm-kernel@lists.infradead.org>, <devicetree@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <stable@vger.kernel.org>
Subject: Re: [PATCH v3 0/3] arm64: dts: hi3798cv200: fix GICR size, add cache
 info, maintenance irq and GICH, GICV spaces
References: <20240219-cache-v3-0-a33c57534ae9@outlook.com> <SEZPR06MB695952078B51C4549191F8AB962B2@SEZPR06MB6959.apcprd06.prod.outlook.com> <65F03D79.2070008@hisilicon.com> <SEZPR06MB69599C39A47E625A0C3CB83F962B2@SEZPR06MB6959.apcprd06.prod.outlook.com>
In-Reply-To: <SEZPR06MB69599C39A47E625A0C3CB83F962B2@SEZPR06MB6959.apcprd06.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Hi Yang,

On 2024/3/12 19:46, Yang Xiwen wrote:
> On 3/12/2024 7:33 PM, Wei Xu wrote:
>> Hi Yang,
>>
>> On 2024/3/12 19:19, Yang Xiwen wrote:
>>> On 2/19/2024 11:05 PM, Yang Xiwen via B4 Relay wrote:
>>>> The patchset fixes some warnings reported by the kernel during boot.
>>>>
>>>> The cache size info is from Processor_Datasheet_v2XX.pdf [1], Section
>>>> 2.2.1 Master Processor.
>>>>
>>>> The cache line size and the set-associative info are from Cortex-A53
>>>> Documentation [2].
>>>>
>>>>   From the doc, it can be concluded that L1 i-cache is 4-way assoc, L1
>>>> d-cache is 2-way assoc and L2 cache is 16-way assoc. Calculate the dts
>>>> props accordingly.
>>>>
>>>> Also, to use KVM's VGIC code, GICH, GICV registers spaces and maintenance
>>>> IRQ are added to the dts with verification.
>>>>
>>>> [1]: https://github.com/96boards/documentation/blob/master/enterprise/poplar/hardware-docs/Processor_Datasheet_v2XX.pdf
>>>> [2]: https://developer.arm.com/documentation/ddi0500/j/Level-1-Memory-System
>>>>
>>>> Signed-off-by: Yang Xiwen <forbidden405@outlook.com>
>>>> ---
>>>> Changes in v3:
>>>> - send patches to stable (Andrew Lunn)
>>>> - rewrite the commit logs more formally (Andrew Lunn)
>>>> - rename l2-cache0 to l2-cache (Krzysztof Kozlowski)
>>>> - Link to v2: https://lore.kernel.org/r/20240218-cache-v2-0-1fd919e2bd3e@outlook.com
>>>>
>>>> Changes in v2:
>>>> - arm64: dts: hi3798cv200: add GICH, GICV register spces and
>>>>     maintainance IRQ.
>>>> - Link to v1: https://lore.kernel.org/r/20240218-cache-v1-0-2c0a8a4472e7@outlook.com
>>>>
>>>> ---
>>>> Yang Xiwen (3):
>>>>         arm64: dts: hi3798cv200: fix the size of GICR
>>>>         arm64: dts: hi3798cv200: add GICH, GICV register space and irq
>>>>         arm64: dts: hi3798cv200: add cache info
>>>>
>>>>    arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 43 +++++++++++++++++++++++++-
>>>>    1 file changed, 42 insertions(+), 1 deletion(-)
>>>> ---
>>>> base-commit: 8d3dea210042f54b952b481838c1e7dfc4ec751d
>>>> change-id: 20240218-cache-11c8bf7566c2
>>>>
>>>> Best regards,
>>> May someone apply this patchset to their tree so that it can land in stable at the end? This is a fix, not adding new functionalities. It's been 2 weeks already.
>>>
>> Sorry for the delay, I am too busy to catch up with this cycle.
>> I will go through this patch set and maybe apply it during the next cycle.
> 
> 
> No problem. I'm just a bit worried if this patch is getting lost. It's good to know it's still maintained. Because i've seen some maintainers not reviewing any patches for over 1 year already, with their names and emails still in MAINTAINERS.

Thanks for the understanding!

> 
> 
> By the way, I think fixes and new features are in different cycles? Most maintainers seem to have multiple branches to handle this.

Yes, they can be in different cycle. But now is the merge window.

Best Regards,
Wei

> 
> 
>>
>> Best Regards,
>> Wei
> 
>