From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=185.246.84.56 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793318567; b=WpBgv8c0tC8QFRdImEU3HG74eTAV2Qvs4QNJwYnlrQkjg0j+QirQMcTztiuaEfZbrYWB gX1NenLSfmFadfS2OCCTmlSTITsw8WM1AbjicX82AZxboszCGVk011OehPVCAmGmsqdmF WXB0FB/1M9SMcTbm5obIi5tpaI6RkCBpS17SqxsQLsqXL3l1pCrX5UmQusrhvoOr0OIhm Cuxa2gvEZ0ohtKvuXx6Ys3901x9IeLgTXLR9PIRpI8vTHwgKoiuSeuk2Ovuc7wFIF4VHO 4mtUHYz6vT8Mtbm6iC1yU8HYshpWDahhS44Smzob7hft7db0hYN5v31RrKR4DaLCV3w== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793318567; h=DMARC-Filter:Received:Received:Received:DKIM-Signature:Date:From:To: Cc:Subject:Message-ID:In-Reply-To:References:Organization:X-Mailer: MIME-Version:Content-Type:Content-Transfer-Encoding: X-Last-TLS-Session-Version; bh=EekVTKvOeeC7YsplvAwGdEYQ+UvW9EdugEoPsQ9stwE=; b=pG7WirRb9BETfC0/76K2BarbSvDzwCE+PRXLZcpXIwHOM0NVMDy+5tB2YFg0Hl9yXhA9 LoSd6SMHeoWP+qR5rsrfOQvtUJdhguVhyAUR8k8Fl4VKWKYH9Ca01efWVEej2jOI1Diss WGtUYLIucbjUCXk/S2QE2BlcQEZNzMTWAhVfizpUfUvR3nnuQuREcjSk0OsYoThzL0Nlr 6SC6Z+U9J9Ck9BxTnyVcWEcmrwltjo0eL4fpClzbzRIHt/5f6rQfi+e5WO8axyb+MurHp eG86bGYGxk1tkRzsYOZqnNyj2jCB7X/UiUXFIqVVyY/7wkMIIkKWIhIEviBL/QkI7tQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass header.d=bootlin.com header.i=@bootlin.com header.a=rsa-sha256 header.s=dkim header.b=tFz8MHm1; arc=none smtp.remote-ip=185.246.84.56 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 12CC5606A31F; Fri, 30 Oct 2026 00:02:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 12CC5606A31F Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=bootlin.com header.i=@bootlin.com header.a=rsa-sha256 header.s=dkim header.b=tFz8MHm1 Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id 5F16B1A1382; Fri, 30 Oct 2026 00:02:43 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 308106076A; Fri, 30 Oct 2026 00:02:43 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 5DE84103287DA; Fri, 30 Oct 2026 01:02:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1793318557; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=EekVTKvOeeC7YsplvAwGdEYQ+UvW9EdugEoPsQ9stwE=; b=tFz8MHm16YurNh2mIlIObooIYNsnhPs4cj3xNZ/bT4oXGpWFRAXR1ilWe2CvEdZ5RO1PPx LhyyqVDYi2l57JpiH2vwFLCfaXHw1WSFaUPT8lQhGdQl5+SwHOV2+aID9eeHE9ifID4Wnj 3nA3XaC4DTitcDWgnFv0F4kTYhzVHCu9tp7Rw3UhlDTsz5lsgoYVNvWjROitSNF0IQtVh/ nwZ8O+4cpqdUpl+WWRjg2mHAW577eyN3bJelcrmO7CGqwExB5HkygFQiZKfppR0Di1N1vs 3MpxzOIQoXLBxqp3BTjtANZjLfu/lzlXJEwhgbHETx9IGMFJP8tXiYr2x7DDLg== Date: Fri, 30 Oct 2026 01:02:28 +0100 From: Herve Codina To: David Gibson Cc: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Laurent Pinchart , David Lechner , Ayush Singh , Geert Uytterhoeven , devicetree-compiler@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree-spec@vger.kernel.org, Hui Pu , Ian Ray , Luca Ceresoli , Thomas Petazzoni , Frank Li Subject: Re: [PATCH v3 15/15] Introduce v18 dtb version Message-ID: <20261030010228.34d9daca@bootlin.com> In-Reply-To: <20261021155923.55e48904@bootlin.com> References: <20260826083146.304291-1-herve.codina@bootlin.com> <20260826083146.304291-16-herve.codina@bootlin.com> <20260925152157.511dc65c@bootlin.com> <20261013190347.4f1d9b9d@bootlin.com> <20261019151121.26d99f30@bootlin.com> <20261021155923.55e48904@bootlin.com> Organization: Bootlin X-Mailer: Claws Mail 4.4.0 (GTK 3.24.52; x86_64-redhat-linux-gnu) X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Last-TLS-Session-Version: TLSv1.3 Hi David, I know you are busy but if you could give me your opinion on this last message that would be greatly appreciated. I've started to prepare the next iteration of the series adding support for "structured" tags and their definition need to be stable to move forward. The question to answer to complete the definition of the "structured" tag format is: Should SAFE_SKIP bit be re-introduced? IMHO, it should. Best regards, Hervé On Wed, 21 Oct 2026 15:59:23 +0200 Herve Codina wrote: > Hi David, > > On Wed, 21 Oct 2026 13:26:49 +1100 > David Gibson wrote: > > > > > Correct. Btw, I know I suggested "skippable tag" as a term, but given > > how that gets kind of misleading in the case of writes, I'm coming to > > prefer the orignal "structured tag" term. > > Ok, no problem to switch back to "structured tag". On my side also, I prefer > this term. > > Now I think that the bit indicating if a structured tag can be skip or not > should be kept. I know the we can use "old" tag format when a tag cannot be > skipped but I thing that using structured tags for those tags can lead to some > benefit. For instance, in fdt_tag_next() we can benefit of the data size > encoded for structured tags for all king of structured tags (skippable and not > skippable) and retrieve the next tag without the need for parsing data related > to a tag. When tag has a string as data, without the length we have to scan the > string to find its end. Of course we can add the length if the tag definition > but this is automatically implied if we use a structured tag. > > So for structured tag, I can propose: > - bit 31: 1 to identify a structured tag > - bit 30: SAFE_SKIP bit (1 if we can skip, O otherwise) > - bit 29..24: Data lendth encoding > 0b000000: No data > 0b000001: 1 32bit word of data > ... > 0b111110: 63 x 32bit words data > 0b111111: varlen encoding (1 32bit word added after the tag to encode the > data length in bytes. > - bit 23..0: Tag id > > Without the SAFE_SKIP bit, all structured tags must be skippable. IMHO, we > could regret this limitation in the future. > > The cost of the SAFE_SKIP bit is not a lot. When we check to see if an > unkwown tag can be skipped, we are going to move from > if (tag & 1<31) > to > if ((tag & (1<31 | 1<<30)) == (1<31 | 1<<30)) > > IHMO, this is acceptable. > > Of course, if the SAFE_SKIP bit is re-introduced, I will also re-add the test > checking that unknown structured tag that cannot be skipped leads to an error. > > Best regards, > Hervé -- Hervé Codina, Bootlin Embedded Linux and Kernel engineering https://bootlin.com