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/[email protected]/ > > > >> https://lore.kernel.org/linux-arm-msm/[email protected]/ > > > > > > > > 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
