From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 009E824293C for ; Fri, 9 Jan 2026 09:52:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767952347; cv=none; b=rKQ/TKxd8YOnQXCHBHdBCsUL8u7iuOuSEXJQkdcXuzWQ/H+kCUIpkIYc6f62yXXO+ITqPvSivqa+YCQJAKY4yqfBczLS91Aku/uPWWTIpJTofUNYnZmIiVoYZDuJ+uCyhV4+EL4o6V8QX97uvlE3drgfXpyG1mOhS+O6FnHWJ20= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767952347; c=relaxed/simple; bh=fQ1tJffQT1qprHD9d7yQZUs66p4r8g3jJv8f9N6H0Jw=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=LYrmAbBk9Y+zkWRUWRLdhBzI35p736tk7lgiGitP5ke9hxIqibv0i+LOuHpcZnl18uWEFsrDnycpp7kEjH1rw9VLkTXw1SRpcxVRrQtBJGsnHJtmWIP87t6O4i/VG52TyXGSqDsiCc1KEUIUPhpZIT2GAVaWBGxg+FuIUguuTys= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=h+v9zXR3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="h+v9zXR3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A29D7C19424 for ; Fri, 9 Jan 2026 09:52:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767952346; bh=fQ1tJffQT1qprHD9d7yQZUs66p4r8g3jJv8f9N6H0Jw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=h+v9zXR3HWbP85MwT80vJwaM9+gGJ2B1x1jbzhTJvwbE7JtROxnKqjBzFpB6/Bppb KCnY67jWW5w7iztq15s8GJ3N4TbFJpDSyf6GHSmmsno/4qoy4R/gL3ZQyUSW/AgXi6 4klsGdtiDBn8RG/wEkhreeHE2/yNvuwryTCfEFjM/99Sw9iF9M60h0oVhjXyaHXxLA yg79WP6Q1ClZybgSFBigxf2kOuMT72c7uxEFohv26IOSoXF9IuOUVJJLDbX71s55GK Oyd9dbUiztSe+Kyb/QuSVf1uoNZXCg8ENF7292SyYWrr0oNJgNosGNvxn6pZGTedTo 1M7xXQm1mm6Hg== Received: by mail-yx1-f42.google.com with SMTP id 956f58d0204a3-6446d7a8eadso3637893d50.0 for ; Fri, 09 Jan 2026 01:52:26 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCUYp85/qHM3a1+zOJTORjjb+pEzUS2KaZ688eN9A4UNRZ8Y/VsWB3hadN/gFwVOYfc1IWZD47L5PzgUgkI=@vger.kernel.org X-Gm-Message-State: AOJu0YxVbZy1Z+KjHe1Q38gehzekCsjIogL9KbEMjAgYJ+4HtH+WO1XC pZfbJyUqOfE1ShBp+Xfs6RKyO75gET7tXPyIAnIMDwbp579bAECPkWU35XgxIfr4SDClfyY3HyR 479fLsfTQurqP4THWtTQJAFY2EGDz8/k= X-Google-Smtp-Source: AGHT+IFl+ErtwuC5vJB7FQDU7XpIoJtBTN3jHxe+AWD5ehVTJ4NoJsDHhflCFGEIV2ALI+7K1MxEBTnysWlIEE1/Is4= X-Received: by 2002:a05:690e:1882:b0:648:3d3:790a with SMTP id 956f58d0204a3-64803d381e8mr1065328d50.17.1767952345952; Fri, 09 Jan 2026 01:52:25 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260107-mtd-memregion-v3-0-f9fc9107b992@bootlin.com> <20260107-mtd-memregion-v3-3-f9fc9107b992@bootlin.com> In-Reply-To: <20260107-mtd-memregion-v3-3-f9fc9107b992@bootlin.com> From: Linus Walleij Date: Fri, 9 Jan 2026 10:52:15 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AZwV_Qg5QQFy3AmO1hR3ASLJtvCVyx_cqfPdctjeTMOQ0Cjj3dOpo4MEYroa2cg Message-ID: Subject: Re: [PATCH v3 3/4] dt-bindings: mtd: physmap: Allow using memory-region to access memory resources To: Gregory CLEMENT Cc: Rob Herring , Linus Walleij , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Krzysztof Kozlowski , Conor Dooley , Thomas Petazzoni , Vladimir Kondratiev , =?UTF-8?Q?Beno=C3=AEt_Monin?= , =?UTF-8?B?VGjDqW8gTGVicnVu?= , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mtd@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Gregory, thanks for your patch! On Wed, Jan 7, 2026 at 2:05=E2=80=AFPM Gregory CLEMENT wrote: > Enable access to memory resources not only via I/O address using reg, > but also through a portion of main memory using memory-region. To > achieve this, new compatible strings have been introduced: mtd-mem and > mtd-memro. > > Signed-off-by: Gregory CLEMENT I have two issues with this patch: 1. It needs a description: telling us when to use this and why, and what makes it necessary to use these new bindings instead of existing bindings, like the following: 2. To me this looks suspiciously similar to reserved RAM, "reserved-memory"= . Documentation/devicetree/bindings/reserved-memory/phram.yaml Documentation/devicetree/bindings/nvmem/rmem.yaml Documentation/devicetree/bindings/reserved-memory/ramoops.yaml Also see the dtschema reserved-memory: https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/rese= rved-memory/reserved-memory.yaml Why is this using "mtd,*" compatibles? What makes is a "memory technology device", which is admittedly a loose term but usually means some kind of persistent memory such as flash. This does not look persistent at all. To me it seems more related to specific Linux-lingo around the MTD subsystem and just happens to be handled inside that subsystem in Linux. Which means it has nothing to do inside a (OS-neutral) DT binding. So I'm a bit concerned, but maybe I misunderstood something! Yours, Linus Walleij