From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E4763336881 for ; Wed, 12 Aug 2026 11:26:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786533967; cv=none; b=HBaGATmlZ6uhKY1wDNVwxy1Dt4lVFbIFK4/h11OS0dtheOPkzm6FaVQCwjD+bAz8WK7/KP9LtbbnPQl6Td7LRz0SWasg9LCQ0v1VN1vlJ9C92jsyoYcMMc4q3Bi+lSXbkqIKOittUIWsp3kkXqqwOId8Ttga+VDF+HJHFeTYhgk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786533967; c=relaxed/simple; bh=WoKWEWKlv1+PeyUN1OlqnAXZmrjz3ThOQrXHDS8EOWI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=A7L9AkIT3d8khvME/dpEKBIMJwQraJifdaQ3LC09xewIQQclsBsBERIjs21j9AW3cMhsyAxW0gjQYCPfra5+uNGNkpdtARQ3xMstYiIvTzII5S3f2t28Jmw/aLGtfPH+2whiLwNfUTXY+tWX65cM452pCFIyKBqjYY8wFCHK1F4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=DorRFm4I; arc=none smtp.client-ip=209.85.128.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="DorRFm4I" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-495635a85d2so6068945e9.0 for ; Wed, 12 Aug 2026 04:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786533959; x=1787138759; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ey4E5gbb1zGfpxU9QFub0aU8JCEKCtqwD4Rbc0BSyts=; b=DorRFm4IacUf7NsIeB+lrEAcJTZCW8NS68j7RoSsCM+dm++yg/TNKNJU2lnRaTF711 X6DzbaC3iPlgJ95PMEZy4ecxi6gGDiSXVraQEpzdGSaFlFw7sYPy72WtA+Nyx+68aRs9 vyJ+uajT/aUamQxTJmuE2FovJxcJ6xXTp/9u9BLYq3O1Zbzlgs+4u4BuLe4B5cmdiG6y BPHq3ietiA43cZsy6W2IKro0j55/ux32bRYIHWAYppXasyaQ5dqetvIN59W9V4uLpwtr rmSWqIMzHH/ULUuZ4LG3O7e/d9L2W7KHyTr+fY3aQ8xn4chZRKfpa4d9/2e01P1Ru09u Z6Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786533959; x=1787138759; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ey4E5gbb1zGfpxU9QFub0aU8JCEKCtqwD4Rbc0BSyts=; b=UESsfGucMmBKwxjcTLFR4UogAUEwB15ffYPCE1u/bh0MH5JRo+il2PGxdb++Iu+/PB weRyyGD8VkVizG9H6QgNmrOKsaGhTVGtDJ7GyBYYQ30l1/WkLYMmEw9V88YPxxmWjvDZ oUHWLFl1Lm3VyNDdSWezzObLSWRt44gdErPBE5SjzovW/kL/exv2RKf3YgPZRo08MOmI 4SAKzOL3hjtY6LHOWhsdiyNoBIZ5Fq8pxVJqaOZC3GCH9GWPE0Nzq6bDa1nVEG+LC6EV ntOHTEKCAoWrthDSu+rddCzmUeNNpjyEYuiIE+s9fsrUWXeFLJqxwAap8ie1611fGAVG vnvA== X-Forwarded-Encrypted: i=1; AHgh+Rp/mVuBi/OkewnNPVHMnXetSTmgeZjpu6HGukQvfsi/6Z+e2fXsBZhG/PInhgGRvLYkzje0WHZr21JQjsI=@vger.kernel.org X-Gm-Message-State: AOJu0YwZOznDZQ1urKoOw7LoykWDlnMT1kW1uitm+emq2YTJXR+3yMVe EC16c2YSZixcZYhyXvZa9xXjRB1h5fcyWO+Aq4OjR/nMkcjsIrMqDZZo X-Gm-Gg: AR+sD13mvXfYUbUJ17RjpCHR5agkLXXlMhRNfrG49d2RBt90VlPoKz602rrzpWouwmh dMw0J4Q5igQYBvts8k6v0leCD5M+boR6KHKUJ5u1bYfpfKeZpY4tJOoVGsow6ShCRRXTzq0TisT /QUIs0/0y6AIFQd6I34nZSebBhVdksl5VFjMFkPLbnrNdUsbEhz4slSTRRtoVUzi5Wap/Z4NSjN 9zCyFEPtLrn3YxP+LHTvpJiaxTooO6+noT7vB06YcqM1pjAzvUN5EzsK+9fzs8Lvwe5Jiub7Sgg CDPmbEr35+sM4ck8i6WQGMpAAuNQ3RJE01eDoTVKpfr3LFVLtHfMwYXDFljfYKvw2KwpFHg2jbO FN0KBUetNqSWa8Awpvxcj2HiU969FMXHozGJheG/6ofhaFXZfJPabiRtVaZn5QsW563k1yHucxs 1ZXZ+70UGF6D89UF1hmhKJ6jVgxWiud4GZFsx9gVwfUWS2oRaNX/mRh0Qs55W17ZNwV8ZE+8nOs pUqW29Hi1YMWohinzqCJw== X-Received: by 2002:a05:600c:4f87:b0:499:48be:3189 with SMTP id 5b1f17b1804b1-4997bf81217mr46280755e9.0.1786533958498; Wed, 12 Aug 2026 04:25:58 -0700 (PDT) Received: from [10.25.219.170] ([128.77.115.157]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4997b238a9asm42581695e9.3.2026.08.12.04.25.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Aug 2026 04:25:58 -0700 (PDT) Message-ID: <36260069-cd81-4744-b5fb-8467f7874851@gmail.com> Date: Wed, 12 Aug 2026 04:25:56 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/4] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names" To: "Peng Fan (OSS)" , "Frank Li (OSS)" Cc: Bjorn Andersson , Mathieu Poirier , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Sascha Hauer , Frank Li , Fabio Estevam , "Daniel Baluta (OSS)" , Francesco Dolcini , "linux-remoteproc@vger.kernel.org" , "devicetree@vger.kernel.org" , "imx@lists.linux.dev" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" References: <20260730163412.1145-1-laurentiumihalcea111@gmail.com> <20260730163412.1145-2-laurentiumihalcea111@gmail.com> Content-Language: en-US From: Laurentiu Mihalcea In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 8/3/2026 2:03 AM, Peng Fan (OSS) wrote: >> Subject: Re: [PATCH v3 1/4] dt-bindings: remoteproc: imx_rproc: >> document optional "memory-region-names" >> >> On Thu, Jul 30, 2026 at 09:34:09AM -0700, Laurentiu Mihalcea wrote: >>> From: Laurentiu Mihalcea >>> >>> The carveout region names are derived based on the DT node names. >>> Because of this, the DT node names are ABI, which is not supposed to >> happen. >>> >>> Fix this by documenting an additional, optional property: >>> "memory-region-names". This way, the software will have a way to >> build >>> the carveout region names without relying on the DT node names. >> >> "After update all existing DT tree, this will be required. >> >>> >>> Signed-off-by: Laurentiu Mihalcea >>> --- >> >> Additional information to help understand why it is important. >> >> 1. at thread wrong use vdevbuffer insteand vdev0buffer as node name >> https://lore.kernel.org/imx/20260705202439.3F5771F000E9@smtp.k >> ernel.org/ >> 2. similar case happen at >> https://lore.kernel.org/imx/20260715071741.79CA81F000E9@smtp.k >> ernel.org/ >> >> Suppose these problem should be detected by dt binding check instead >> of sashkio ai. >> >> >>> .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git >>> a/Documentation/devicetree/bindings/remoteproc/fsl,imx- >> rproc.yaml >>> b/Documentation/devicetree/bindings/remoteproc/fsl,imx- >> rproc.yaml >>> index c18f71b64889..8e3e6676a95e 100644 >>> --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx- >> rproc.yaml >>> +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx- >> rproc.yaml >>> @@ -62,6 +62,10 @@ properties: >>> minItems: 1 >>> maxItems: 32 >>> >>> + memory-region-names: >>> + minItems: 1 >>> + maxItems: 32 >>> + >> >> Need restrict names >> >> memory-region-names: >> description: >> Names for the memory-region phandles. Each entry must be one of >> the >> following recognized names. "vdev0buffer" is the shared buffer for >> virtio device 0, handled automatically by the rproc virtio framework. >> "vdevring" (e.g. "vdev0vring0", "vdev0vring1") are the virtio >> vring buffers for device N, also managed by the virtio framework. >> "rsc-table" is the resource table region used to share the resource >> table between Linux and the remote processor when it is pre- >> loaded in >> memory. All other entries are treated as generic carveout regions >> that >> are mapped and made available to the remote processor. >> minItems: 1 >> maxItems: 32 >> items: >> anyOf: >> - const: rsc-table >> - pattern: "^vdev[0-9]+buffer$" >> - pattern: "^vdev[0-9]+vring[0-9]+$" > > There might be other entries such as m4_reserved or m7_reserved Then how about an additional pattern? Something like: - pattern: "^remote-reserved[0-9]$" I believe a board could, in theory, have more of these additional carveouts, depending on the range of firmware provided by the vendor's BSP (or the community) for that particular board. Still need to put this in code and test it, though. Peng Fan, Frank Li, would this work for the NXP platforms? Franceso, could you please let me know if this'll work for the Toradex platforms?