From: Rob Landley <rob@landley.net>
To: Rob Herring <robh@kernel.org>, "D. Jeff Dionne" <jeff@coresemi.io>
Cc: Krzysztof Kozlowski <krzk@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Artur Rojek <contact@artur-rojek.eu>,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] dt-bindings: net: Add support for J-Core EMAC
Date: Thu, 21 Aug 2025 16:02:41 -0500 [thread overview]
Message-ID: <4df745a6-2997-4eee-87b1-0c77ff46cfdd@landley.net> (raw)
In-Reply-To: <20250820213959.GA1242641-robh@kernel.org>
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
next prev parent reply other threads:[~2025-08-21 21:21 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-15 19:48 [PATCH 0/3] J2 Ethernet MAC driver Artur Rojek
2025-08-15 19:48 ` [PATCH 1/3] dt-bindings: vendor-prefixes: Document J-Core Artur Rojek
2025-08-16 8:18 ` Krzysztof Kozlowski
2025-08-16 8:22 ` Geert Uytterhoeven
2025-08-16 9:40 ` Krzysztof Kozlowski
2025-08-16 10:34 ` Artur Rojek
2025-08-16 9:40 ` Krzysztof Kozlowski
2025-08-15 19:48 ` [PATCH 2/3] dt-bindings: net: Add support for J-Core EMAC Artur Rojek
2025-08-16 8:19 ` Krzysztof Kozlowski
2025-08-16 12:06 ` Artur Rojek
2025-08-18 6:43 ` Geert Uytterhoeven
2025-08-18 8:07 ` Krzysztof Kozlowski
2025-08-18 8:21 ` D. Jeff Dionne
2025-08-18 9:58 ` Krzysztof Kozlowski
2025-08-18 10:57 ` Geert Uytterhoeven
2025-08-18 13:41 ` Krzysztof Kozlowski
2025-08-18 13:55 ` D. Jeff Dionne
2025-08-20 21:39 ` Rob Herring
2025-08-21 21:02 ` Rob Landley [this message]
2025-08-18 15:03 ` Rob Landley
2025-08-15 19:48 ` [PATCH 3/3] net: j2: Introduce " Artur Rojek
2025-08-15 20:16 ` Andrew Lunn
2025-08-15 20:52 ` Artur Rojek
2025-08-15 21:14 ` Artur Rojek
2025-08-15 22:38 ` Andrew Lunn
2025-08-15 23:25 ` Artur Rojek
2025-08-16 0:18 ` Andrew Lunn
2025-08-16 13:40 ` Artur Rojek
2025-08-16 15:04 ` Andrew Lunn
2025-08-17 12:04 ` Artur Rojek
2025-08-17 18:09 ` Rob Landley
2025-08-17 19:39 ` Andrew Lunn
2025-08-17 4:29 ` D. Jeff Dionne
2025-08-17 11:50 ` Artur Rojek
2025-08-17 16:04 ` Rob Landley
2025-08-17 16:08 ` Andrew Lunn
2025-08-15 23:26 ` Stephen Hemminger
2025-08-16 11:24 ` kernel test robot
2025-08-19 21:09 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4df745a6-2997-4eee-87b1-0c77ff46cfdd@landley.net \
--to=rob@landley.net \
--cc=andrew+netdev@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=contact@artur-rojek.eu \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=geert@linux-m68k.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=jeff@coresemi.io \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®