From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B7AAA45D44; Tue, 19 Nov 2024 17:41:32 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A91D1402E9; Tue, 19 Nov 2024 17:41:32 +0100 (CET) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mails.dpdk.org (Postfix) with ESMTP id 86D614029B for ; Tue, 19 Nov 2024 17:41:30 +0100 (CET) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E075520E3; Tue, 19 Nov 2024 08:41:59 -0800 (PST) Received: from [192.168.50.107] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4E8453F66E; Tue, 19 Nov 2024 08:41:29 -0800 (PST) Message-ID: Date: Tue, 19 Nov 2024 16:41:27 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 3/4] dts: add per-test-suite configuration Content-Language: en-GB To: Dean Marx Cc: dev@dpdk.org, Paul Szczepanek , Patrick Robb References: <20240906161355.701688-1-luca.vizzarro@arm.com> <20241108134532.130681-1-luca.vizzarro@arm.com> <20241108134532.130681-4-luca.vizzarro@arm.com> <48bf44a8-d483-4022-bebf-b90d50c7c5a3@arm.com> From: Luca Vizzarro In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 19/11/2024 16:31, Dean Marx wrote: >> So... this is a weird one. I've integrated the code generation under >> dts-check-format.sh, so nobody should really worry about it, as that >> should be run before submitting. If it's not, then the CI will >> eventually pick it up when dts-check-format will be in place. > > Right, and that definitely makes sense logically but I think maybe > even just throwing in a comment in conf.yaml similar to the one you > used below (timeout: 20 # optional field from > HelloWorldConfig) would be beneficial, even if just to show where the > customized fields should go. If you'd rather leave it as is though > that's totally fine with me, this is kind of a nitpick suggestion > anyways Oh ok, yes it makes sense. It's a good shout. Although, this patchset may change how it will be once we start splitting the configuration file in multiple ones. I guess we'll see what happens then! This will probably stay on standby until we reach an agreement on what to do. Thank you for your review! Luca