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 A0867C369AB for ; Thu, 24 Apr 2025 05:12:23 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.965783.1356201 (Exim 4.92) (envelope-from ) id 1u7osP-00025I-9x; Thu, 24 Apr 2025 05:11:57 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 965783.1356201; Thu, 24 Apr 2025 05:11:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1u7osP-00025B-7N; Thu, 24 Apr 2025 05:11:57 +0000 Received: by outflank-mailman (input) for mailman id 965783; Thu, 24 Apr 2025 05:11:55 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1u7osM-000255-9I for xen-devel@lists.xenproject.org; Thu, 24 Apr 2025 05:11:55 +0000 Received: from mail-10630.protonmail.ch (mail-10630.protonmail.ch [79.135.106.30]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9faf1985-20ca-11f0-9ffb-bf95429c2676; Thu, 24 Apr 2025 07:11:48 +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: 9faf1985-20ca-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1745471506; x=1745730706; bh=rWWtHvNVY1LG4DRwU/05iAowOTcIQPz03VIwuRFxkV0=; 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:List-Unsubscribe:List-Unsubscribe-Post; b=lEtPpZkcCwWzi7ADFCPSsJjgJlXl2QWyQa9K6bj5nJCNU8Lu/p2VKSXKEuch6oZrA 6btInHKRncIYYRruwvB79nDqhmGcH/+xuI8TsQ8DBJXSfwvKQYXT1wVQMouMF3JIcg vTM4zLjyldTupY6i038J8YM3zEOWFpe/pjpagK6Oj3K6f+bDySeOWT4E3HxRVnliXL 0NcHP/LfHXTIexXENGOCfZmCdRgyhmNAdZ4+9XXmyeDJeXl3xL4nEkAKsxMcUWW+Re sJ0mEpvvQF8E68mqUkSSmebBHTzo4fyCvpiJVlAZtVsQZs0KSVRqx6to/BwnzHqKV4 b+Ubs880gsaCw== Date: Thu, 24 Apr 2025 05:11:40 +0000 To: Jan Beulich From: dmkhn@proton.me Cc: Alejandro Vallejo , xen-devel@lists.xenproject.org, "Daniel P. Smith" , Andrew Cooper , =?utf-8?Q?Roger_Pau_Monn=C3=A9?= , Anthony PERARD , Michal Orzel , Julien Grall , Stefano Stabellini , Bertrand Marquis , Jason Andryuk Subject: Re: [PATCH v4 07/13] x86/hyperlaunch: obtain cmdline from device tree Message-ID: In-Reply-To: <4813aeb3-72c6-4705-8591-1af63ec05ae8@suse.com> References: <20250417124844.11143-1-agarciav@amd.com> <20250417124844.11143-8-agarciav@amd.com> <4813aeb3-72c6-4705-8591-1af63ec05ae8@suse.com> Feedback-ID: 123220910:user:proton X-Pm-Message-ID: 662deea00ef6b1c44f744e7c8238a5e4f712a082 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 23, 2025 at 03:08:18PM +0200, Jan Beulich wrote: > On 23.04.2025 15:01, Alejandro Vallejo wrote: > > On Fri Apr 18, 2025 at 11:53 PM BST, dmkhn wrote: > >> On Thu, Apr 17, 2025 at 01:48:29PM +0100, Alejandro Vallejo wrote: > >>> --- a/xen/common/domain-builder/fdt.h > >>> +++ b/xen/common/domain-builder/fdt.h > >>> @@ -9,6 +9,30 @@ struct boot_info; > >>> /* hyperlaunch fdt is required to be module 0 */ > >>> #define HYPERLAUNCH_MODULE_IDX 0 > >>> > >>> +static inline int __init fdt_cmdline_prop_size(const void *fdt, int = offset) > >>> +{ > >>> + int ret; > >>> + > >>> + fdt_get_property_by_offset(fdt, offset, &ret); > >> > >> Perhaps something like > >> > >> (void)fdt_get_property_by_offset... > >> > >> since there's no need to check the return value? > > > > I vaguely seem to remember doing something like that a few years ago > > (because it does show intent and many linters require it) and being tol= d > > not to. But maybe I misremember. I'm definitely happy to use that > > convention here and later unless someone pushes back for some reason. >=20 > Unless we settle on the need for such for Misra's sake, I'd like to ask > to avoid them. We generally try to avoid casts as much as possible. We > then also shouldn't add ones like suggested here. Ack. >=20 > Jan