linux-kernel - Re: [PATCH v2 1/2] dt-bindings: pinctrl: document the Milos Top Level Mode Multiplexer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250708171515.GA640511-robh@kernel.org>
Date: Tue, 8 Jul 2025 12:15:15 -0500
From: Rob Herring <robh@...nel.org>
To: Bjorn Andersson <andersson@...nel.org>
Cc: Krzysztof Kozlowski <krzk@...nel.org>,
	Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
	Luca Weiss <luca.weiss@...rphone.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, linux-gpio@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: pinctrl: document the Milos Top
 Level Mode Multiplexer

On Thu, Jul 03, 2025 at 12:31:46PM -0500, Bjorn Andersson wrote:
> On Thu, Jul 03, 2025 at 01:26:11PM +0200, Krzysztof Kozlowski wrote:
> > On 03/07/2025 12:04, Konrad Dybcio wrote:
> > > 
> > > 
> > > On 03-Jul-25 09:44, Luca Weiss wrote:
> > >> On Thu Jul 3, 2025 at 9:41 AM CEST, Krzysztof Kozlowski wrote:
> > >>> On Wed, Jul 02, 2025 at 05:56:16PM +0200, Luca Weiss wrote:
> > >>>> Document the Top Level Mode Multiplexer on the Milos Platform.
> > >>>
> > >>> What is Milos platform? Does it have some sort of model number how we
> > >>> usually expect? Wasn't this SM7325 or similar?
> > >>>
> 
> Milos is the actual name of the SoC.
> 
> > >>> The problem with such new naming that it awfully sounds like family
> > >>> names, so just expand the name and explain it.
> > >>
> > >> Please go argue with Bjorn/Konrad about this, wasn't my idea.
> > >>
> > >> https://lore.kernel.org/linux-arm-msm/aGMI1Zv6D+K+vWZL@hu-bjorande-lv.qualcomm.com/
> > >> https://lore.kernel.org/linux-arm-msm/b98d305b-247f-415b-8675-50d073452feb@oss.qualcomm.com/
> > > 
> > > Milos is the "real-est" name of this silicon. All the associated
> > > S[AM]|QC[MS]s are just variations of it, with different fusing.
> > > 
> > > You'll stumble upon it across e.g. firmware build strings, as
> > > well as in any documentation pieces.
> > > 
> > > There are various internal reasons for the switch, but the most
> > > obvious external-facing one is not to have the user buy a devkit
> > > and wonder whether they should use QCS9100 or QCS9075 DTB, and
> > > why there's zero drivers code for these magic numbers (they
> > > include SA8775P). We can simply point them to "codename" and
> > > all C code will refer to it as well.
> > 
> > These are different SoCs, optionally with different firmware, so they
> > cannot use the same top-level compatible chain. I hope you did not
> > propose that.
> > 
> 
> No they are not different SoCs, and that's the problem with the current
> naming scheme.
> 
> > For me list like "qcs9100, sa8775p" is clear enough, but if you want
> > "qcs9100, koala-bear" or "brown-bear, koala-bear" it is fine as well.
> > You just cannot use koala-bear for all of them.
> > 
> 
> It looks "clear enough", but it's wrong. The problem is that sa8775p,
> qca9100, and qcs9075 are the "same" hardware and firmware.
> 
> The difference between sa8775p and qcs9100 is the reserved-memory map,
> the difference between qcs9100 and qcs9075 is one IP block being status
> = "okay" vs "disabled", due to fuses.
> 
> It's exactly the same problem we first saw in QRB5165, but we let the
> problem explode. Now we use the names sc7280, sm7325, qcm6490, and
> qcs6490 for the same SoC.
> 
> Using the SoC's actual name here will remove the need for playing games
> with DT includes etc to try to map things to the current naming scheme.
> 
> 
> The one case that isn't being taking care of such naming is when there
> are differences in the firmware. But as can be seen in the "sc7280"
> familiy, those software differences doesn't align with the chosen names.
> And even within a given SoC, with a (overall) given firmware, the
> reserved-memory map ends up differing.
> 
> 
> So, the name of the SoC in this patch is "Milos". We already have ways
> of dealing with firmware and/or hardware variations within one SoC, we
> should use them (and refine them as necessary), rather than pretending
> that something like SM7325 will define those properties.

I for one prefer 1 compatible per die. We often don't know if that's 
the case, but in this case we do so let's take advantage of it. 

Rob