Message-ID: <4df745a6-2997-4eee-87b1-0c77ff46cfdd@landley.net>
Date: Thu, 21 Aug 2025 16:02:41 -0500
From: Rob Landley <rob@...dley.net>
To: Rob Herring <robh@...nel.org>, "D. Jeff Dionne" <jeff@...esemi.io>
Cc: Krzysztof Kozlowski <krzk@...nel.org>,
 Geert Uytterhoeven <geert@...ux-m68k.org>,
 Artur Rojek <contact@...ur-rojek.eu>,
 John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
 Andrew Lunn <andrew+netdev@...n.ch>, "David S . Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, netdev@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] dt-bindings: net: Add support for J-Core EMAC

On 8/20/25 16:39, Rob Herring wrote:
> On Mon, Aug 18, 2025 at 10:55:51PM +0900, D. Jeff Dionne wrote:
>> J-Core SoCs are assembled with an SoC generator tool from standard
>> components.  An SoC has a ROM from soc_gen with a Device Tree binary
>> included.  Therefore, J-Core SoC devices are designed to ‘just work’
>> with linux, but this means the DT entires are generic, slightly
>> different than standard device tree practice.
> 
> Yes. Though doesn't the SoC generator evolve/change? New features in the
> IP blocks, bug fixes, etc. Soft IP for FPGAs is similar I think.

The j-core guys almost never change the hardware interface on a deployed 
I/O device: when the existing interface is too limiting they do a new 
design with a different interface. (You'll notice in the github soc_top, 
components/ has ddr and ddr2, and components/misc has aic and aic2 from 
when the interrupt controller changed, for example. Those aren't version 
numbers, those are rewrites.)

Outputting a different constellation of devices/busses from the SOC 
generator is more akin to running "make menuconfig". There isn't an 
ancestor/descendant relationship there, it's a generator working from a 
configuration to instantiate and connect existing components.

> There
> we typically just require the versioning schema be documented and
> correlate to the IP versions (vs. made up v1, v2, v3).

There hasn't been a new version of the 100baseT specification recently.

The same chunk of bitstream is still driving the same PHY chips on the 
boards (or compatible, long out of patent) via the same small parallel 
bus at 50mhz. The engineers are no more interested in changing the 
kernel side interface than they are in changing the PHY side interface.

> This is all pretty niche I think, so I'm not too concerned about what 
> you do here.

Eh, not that niche. Just hardware development culture rather than 
software development culture. What's the model number on your microwave? 
If you need to replace it, how many versions will you advance?

Chip model numbers tend to be assigned by marketing well after the fact, 
and don't necessarily have a linear relationship even for the big boys 
making central components other people build entire systems around:

https://en.wikipedia.org/wiki/List_of_Qualcomm_Snapdragon_systems_on_chips

The Pentium II's development name was Kalmath, Pentium III was Katmai, 
then Pentium 4 was a space heater and everybody backed up and switched 
to "Pentium M" (which was MEANT to be a mobile chip but was instead a 
"not stupid" chip) and then they did "Core"... And then "Core 2" and 
"Core Duo" were different things and "Core 2 Duo" was both of those 
things, and then they had i3 and i5 and i7 but they all came out at the 
same time...

Jeep produced a "Cherokee" for 50 years and expected the user to step 
from a 1973 model to a 2023 model and be able to drive it the same 
(modulo major flag day changes like stick shift or leaded gasoline) with 
zero learning curve. Hardware developers of today go "here's an sd card, 
it goes click-click into your device and it just works, the only numbers 
you really need to know are price and capacity" (modulo microsd, but 
they still provide adapter sleds).

Software developers think that "DOS 2.0" and "DOS 3.0" or "Windows 3.0" 
and "Windows 3.1" being profoundly different and largely incompatible is 
just normal, and track that stuff minutely.

Different culture.

Rob

Powered by blists - more mailing lists