From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1018AC87FD2 for ; Thu, 31 Jul 2025 21:03:02 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1066436.1431665 (Exim 4.92) (envelope-from ) id 1uhaQP-0005Jc-O1; Thu, 31 Jul 2025 21:02:53 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1066436.1431665; Thu, 31 Jul 2025 21:02:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uhaQP-0005JV-LO; Thu, 31 Jul 2025 21:02:53 +0000 Received: by outflank-mailman (input) for mailman id 1066436; Thu, 31 Jul 2025 21:02:52 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1uhaQO-0005H7-Hz for xen-devel@lists.xenproject.org; Thu, 31 Jul 2025 21:02:52 +0000 Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch [109.224.244.16]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b6e94179-6e51-11f0-a320-13f23c93f187; Thu, 31 Jul 2025 23:02:49 +0200 (CEST) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b6e94179-6e51-11f0-a320-13f23c93f187 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1753995768; x=1754254968; bh=Pyt+yjTjZvwmVwUcfrsF7Lr2ji6VhDTaT8smtailbYc=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=GZPpUgnsRMEUL21bO+0HywzhDnFqVAax45s/Y9GIyO80x3C+N7QFMNZ2jCn24Z3Vc To5DzRRHIxadcD+yfIgA4VQS3ujaTrioQeLlWTFeib1nb+lUScF4RgvatFeYBT/aNQ y3N3QF4USK5Xi4tRJbKsEPNo0FRIlBhtsmZqGCj8F+DUvhK2g70X2/XB4znthf7ERh JbTF4KZytBHQOvSgrpjwwlPV6D7CCXIPRyaMxBg1OlcUPQqUL3wMKmP1RqD/cGyLU1 WBg/NUYZ03uyqVsKYhcmvnwSMnTeNfE1KCl5XtCT+HYRnwLXXVEF5mCX74rZktBcns oDEib0jbTrycA== Date: Thu, 31 Jul 2025 21:02:44 +0000 To: "Orzel, Michal" From: dmkhn@proton.me Cc: xen-devel@lists.xenproject.org, andrew.cooper3@citrix.com, anthony.perard@vates.tech, jbeulich@suse.com, julien@xen.org, oleksii.kurochko@gmail.com, roger.pau@citrix.com, sstabellini@kernel.org, dmukhin@ford.com Subject: Re: [PATCH v1 02/16] arm/vpl011: move DT node parsing to PL011 emulator code Message-ID: In-Reply-To: References: <20250624035443.344099-1-dmukhin@ford.com> <20250624035443.344099-3-dmukhin@ford.com> Feedback-ID: 123220910:user:proton X-Pm-Message-ID: e1a258683af1e2e39463a236631c69a5ecd74d4e MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 25, 2025 at 08:57:27AM +0200, Orzel, Michal wrote: >=20 >=20 > On 24/06/2025 23:56, dmkhn@proton.me wrote: > > On Tue, Jun 24, 2025 at 09:49:39AM +0200, Orzel, Michal wrote: > >> > >> > >> On 24/06/2025 05:55, dmkhn@proton.me wrote: > >>> From: Denis Mukhin > >>> > >>> Move vpl011 DT node parsing from common Arm code to PL011 emulator co= de. > >> It's not parsing, it's DT node generation. > > > > Oh, that's right, overlooked. > > Thanks, will update. > > > >> > >> We usually keep all the DT node generation functions in one place. I'm= not sure > >> if we want to move them to respective drivers (i.e. vpl011 to vpl011.c= , gicv3 to > >> gicv3.c, etc.). Not sure what other maintainers think. > >> > >>> > >>> While doing it pick the generic name vuart_add_fwnode() for DT parser= function > >> What 'fw' stands for? Firmware? This function creates DT node for domU= , so it > >> should better be sth like vuart_add_dt_node(). > > > > 'fw' stands for 'firmware'. > > > > It should be some generic name because the function will be used on x86= to > > generate to generate the guest ACPI tables. > I see but maybe vuart_add_node() would be a better choice here. Ack. >=20 > ~Michal >=20