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 for Android: free password hash cracker in your pocket

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

Message-ID: <hdocf4qsja3i5qlj3qzzgfyibgbwytlkmdoc4n4lvryilez5uf@7bwnbnav3bui>
Date: Thu, 10 Jul 2025 15:21:56 -0500
From: Bjorn Andersson <andersson@...nel.org>
To: Rob Herring <robh@...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 Tue, Jul 08, 2025 at 12:15:15PM -0500, Rob Herring wrote:
> 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. 
> 

I like this definition, and to the best of my knowledge these are all
examples of "it's the same die".

Regards,
Bjorn