mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®