[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAODwPW-bwg-CD8qfP0cb58QVFLfJSqj6DhZSQuqHxsEdLz1QDA@mail.gmail.com>
Date: Wed, 23 Jul 2025 14:16:05 -0700
From: Julius Werner <jwerner@...omium.org>
To: Clement LE GOFFIC <clement.legoffic@...s.st.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Julius Werner <jwerner@...omium.org>, Will Deacon <will@...nel.org>,
Mark Rutland <mark.rutland@....com>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Maxime Coquelin <mcoquelin.stm32@...il.com>, Alexandre Torgue <alexandre.torgue@...s.st.com>,
Philipp Zabel <p.zabel@...gutronix.de>, Jonathan Corbet <corbet@....net>,
Gatien Chevallier <gatien.chevallier@...s.st.com>, Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>, Gabriel Fernandez <gabriel.fernandez@...s.st.com>,
Le Goffic <legoffic.clement@...il.com>, linux-arm-kernel@...ts.infradead.org,
linux-perf-users@...r.kernel.org, devicetree@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, linux-clk@...r.kernel.org
Subject: Re: [PATCH v3 07/19] dt-bindings: memory: factorise LPDDR channel
binding into memory channel
> I don't want anything specific so yes it could be cool to have a generic
> node name.
> "sdram-channel" is fine for me.
> @Julius what do you think about it ?
> Is your existing software generating it in the kernel ?
> I'm curious about dynamic node name generation.
I'm fine with whatever for the example here as long as the kernel does
not rely on any specific format. `sdram-channel-X` seems fine.
On our platforms we generate these dynamically in the bootloader based
on what we enumerated during memory training, so there's no kernel
code for it. If you're curious, our bootloader code generating it is
here: https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/refs/heads/main/src/boot/memchipinfo.c#25
(We can update this if there's kernel consensus on a new format, but
we'll still have older platforms that keep running the old
implementation and we also want those to remain compatible with newer
versions of Linux.)
Powered by blists - more mailing lists