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: <3d3g2sq4r7pruu4c2sl2itclx7xuja6inasaicm67t4sx6u5fl@xq5g7h4rabno>
Date: Thu, 3 Jul 2025 12:31:46 -0500
From: Bjorn Andersson <andersson@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>, 
	Luca Weiss <luca.weiss@...rphone.com>, Linus Walleij <linus.walleij@...aro.org>, 
	Rob Herring <robh@...nel.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 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 don't have any concerns with your request of mentioning SM7325 in the
commit messages, for now...

Regards,
Bjorn

> 
> Best regards,
> Krzysztof