Add MaxLinear GSW1xx DSA driver support #1386

peteraxis · 2025-11-13T08:19:58Z

This driver uses mdio port for it raw packets.
This is dependent on patch in libpcap.

peteraxis · 2025-11-13T08:23:27Z

How do I create a dependency to a libpcap change?

guyharris · 2025-11-13T08:35:15Z

A Google search for

make a github change depend on a change in a different github repository

didn't turn up anything that looked easy to do.

Presumably the libpcap change is the-tcpdump-group/libpcap#1578; given that this change won't build without that change, that's probably sufficient.

infrastation · 2025-11-13T10:43:37Z

It would be more useful to put the packet diagrams into tcpdump-htdocs. On this note, what are the two vertical lines to the right? One spans from a field boundary to a field boundary and another spans from a middle of a field to a field boundary. The labels next to them do not seems relevant.

What is the reason the vendor is not allocating an EtherType value?

peteraxis · 2025-11-13T11:23:31Z

It would be more useful to put the packet diagrams into tcpdump-htdocs. On this note, what are the two vertical lines to the right? One spans from a field boundary to a field boundary and another spans from a middle of a field to a field boundary. The labels next to them do not seems relevant.

I tried to fill in similar information as from the version it was based on.

What is the reason the vendor is not allocating an EtherType value?

I don't know, I am not affiliated with MaxLinear. It is currently not allocated with IANA.

peteraxis · 2025-11-14T10:13:20Z

What is the reason the vendor is not allocating an EtherType value?

About the EtherType in linux kernel:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=380e6f3c7bc53c74697423ff3f057138ad2b6d8f

guyharris · 2025-11-14T11:51:06Z

What is the reason the vendor is not allocating an EtherType value?

I don't know, I am not affiliated with MaxLinear. It is currently not allocated with IANA.

IANA doesn't manage EtherTypes, the IEEE does.

If this is referring to ETHERTYPE_GSW1XX = 0x88c3, 88c3 is, according to the IEEE Registration Authority's site, registered to "Infineon Technologies Corporate Research ST" in Munich.

Infineon spun off their wire-based communications division as Lantiq in 2009; they were bought by Intel in 2015, and sold by Intel to MaxLinear in 2020.

So perhaps that EtherType belonged to Infineon when it was first used for this purpose, or perhaps it's now owned by MaxLinear, or Infineon let their former division use it.

peteraxis · 2025-11-14T12:17:01Z

What is the reason the vendor is not allocating an EtherType value?

I don't know, I am not affiliated with MaxLinear. It is currently not allocated with IANA.

IANA doesn't manage EtherTypes, the IEEE does.

If this is referring to ETHERTYPE_GSW1XX = 0x88c3, 88c3 is, according to the IEEE Registration Authority's site, registered to "Infineon Technologies Corporate Research ST" in Munich.

Infineon spun off their wire-based communications division as Lantiq in 2009; they were bought by Intel in 2015, and sold by Intel to MaxLinear in 2020.

So perhaps that EtherType belonged to Infineon when it was first used for this purpose, or perhaps it's now owned by MaxLinear, or Infineon let their former division use it.

Tnx! That make more sense. From the FAQ:

In 2020, MaxLinear acquired the
Connected Home Division business of Intel Corporation,
including the former Intel® product/s referenced in
the title of the attached material.
The MaxLinear logo will be added to the
attached material upon its next revision.
MaxLinear is now the manufacturer of this product, direct any questions
and product support requests to your MaxLinear sales contact,
MaxLinear Sales Representative or Distributor, or login to your myMxL
account and create a new support ticket.

So, it is not out of the blue, it wont be any other users of the ethertype.

For reading the packets in raw gsw1xx format.

peteraxis · 2025-12-05T11:30:29Z

Version 2. Using SpecialTag as name instead of EDSA.

infrastation · 2025-12-08T21:10:33Z

print-dsa-gsw1xx.c

+		if (egress)  {
+			ND_PRINT("Egress Port %d,", GSW1XX_EG_IPN(p));
+			if (ndo->ndo_eflag > 1) {
+				ND_PRINT("TTC %d,", GSW1XX_TTC(p));


Regarding this and other fields: the convention is to have a space after a comma, the value is unsigned, so %u would be less confusing.

Also regarding this specific line, TTC does not exist in egress frames.

infrastation · 2025-12-08T21:19:57Z

print-dsa-gsw1xx.c

+#define GSW1XX_IG_TCE(tag) TOK(tag, 2, 0x40, 6)
+#define GSW1XX_IG_TSE(tag) TOK(tag, 2, 0x20, 5)
+#define GSW1XX_IG_FNL(tag) TOK(tag, 2, 0x10, 4)
+#define GSW1XX_IG_SP(tag) TOK(tag, 2, 0x0F, 0)


As far as the packet diagram shows it, the offset for SP is 5, not 2.

infrastation · 2025-12-08T21:25:26Z

print-dsa-gsw1xx.c

+			}
+		} else {
+			ND_PRINT("Ingress Port %d,", GSW1XX_IG_SP(p));
+			ND_PRINT("MAP %d,", GSW1XX_MAP(p));


If DLPML is a bitmap rather than an integer, it should be printed using bittok2str(), please see commit 0b2041f for an example.

Correction: for ingress frames the port map is TEPML, but the other point still applies.

infrastation · 2025-12-08T21:28:05Z

print-dsa-gsw1xx.c

+#define GSW1XX_MAP_HIGH(tag) TOK(tag, 4, 0xFF, 0)
+#define GSW1XX_MAP(tag) ((GSW1XX_MAP_HIGH(tag) << 8) + GSW1XX_MAP_LOW(tag))
+#define GSW1XX_LEN_LOW(tag) TOK(tag, 7, 0xFF, 0)
+#define GSW1XX_LEN_HIGH(tag) TOK(tag, 6, 0x3F, 0)


Is there any reason not to print the MI and KL2UM bits of byte 6?

infrastation · 2025-12-08T21:29:35Z

print-dsa-gsw1xx.c

+#define GSW1XX_EG_IPN(tag) TOK(tag, 2, 0x0F, 0)
+#define GSW1XX_EG_TC(tag) TOK(tag, 2, 0xF0, 4)
+#define GSW1XX_EG_POE(tag) TOK(tag, 2, 0x80, 7)
+#define GSW1XX_EG_IV4(tag) TOK(tag, 2, 0x40, 6)


Both PPPOE and IPV are in byte 3, not 2.

infrastation · 2025-12-08T21:34:54Z

print-dsa-gsw1xx.c

+
+#define GSW1XX_MAP_LOW(tag) TOK(tag, 3, 0xFF, 0)
+#define GSW1XX_MAP_HIGH(tag) TOK(tag, 4, 0xFF, 0)
+#define GSW1XX_MAP(tag) ((GSW1XX_MAP_HIGH(tag) << 8) + GSW1XX_MAP_LOW(tag))


DLPML is byte 4, not 3; DLPMR is byte 5, not 4. If DLPMR is reserved, it would be best to leave it alone instead of interpreting it as the high part of the port map.

Or rather the actual problem here seems to be that both ingress and egress frames have a "port map" field, which for ingress is called TEPML and is the byte at offset 3, and for egress is called DLPML and is the byte at offset 4. This way, these should be two separate macros saying whether it is ingress or egress and which map it is (for example, GSW1XX_IG_TEPML and GSW1XX_EG_DLPML or something such as that). In any case, the reserved byte in both cases should be out of scope. Please correct me if I misunderstood this.

infrastation · 2025-12-08T21:36:58Z

print-dsa-gsw1xx.c

+
+#define GSW1XX_ET1(tag) TOK(tag, 0, 0xFF, 0)
+#define GSW1XX_ET2(tag) TOK(tag, 1, 0xFF, 0)
+#define GSW1XX_TTC(tag) TOK(tag, 2, 0x08, 0)


TTC is specific to ingress frames, in egress frames these bits are IPN.

So in practical terms this macro should be named GSW1XX_IG_TTC.

infrastation · 2025-12-08T22:06:46Z

print-dsa-gsw1xx.c

+				if (GSW1XX_EG_IPO(p)) {
+					ND_PRINT("IV4 %d,", GSW1XX_EG_IV4(p));
+					ND_PRINT("IPO %d,", GSW1XX_EG_IPO(p));
+				}


After IPO and before the frame length it would be useful to print DLPML (using bittok2str(), as noted just below), MI and KL2UM.

infrastation · 2025-12-08T22:13:39Z

tests/TESTLIST

 edsa-high-vid-e	edsa-high-vid.pcap	edsa-high-vid-e.out	-e

+# MaxLinear DSA tag tests
+gsw1xx		gsw1xx.pcap		gsw1xx.out -n -e


Please add

gsw1xx-ee gsw1xx.pcap gsw1xx-ee.out -n -e -e

to test the new code paths specific to -v. I am not sure whether -ee is the best way to hinge this, but whichever arrangement is in place, it should be tested.

infrastation · 2025-12-08T22:13:59Z

print-dsa-gsw1xx.c

+				ND_PRINT("TTC %d,", GSW1XX_TTC(p));
+				ND_PRINT("FNL %d,", GSW1XX_IG_FNL(p));
+				ND_PRINT("IE %d,", GSW1XX_IG_IE(p));
+                                ND_PRINT("TSE %d,", GSW1XX_IG_TSE(p));


Indentation is off at this line.

infrastation · 2025-12-08T22:20:11Z

print-dsa-gsw1xx.c

+			ND_PRINT("GSW1XX ");
+		else
+			ND_PRINT("GSW1XX Unknown 0x%04x, ", sptag_etype);
+	}


What is the purpose of this differentiation based on ndo_eflag and/or sptag_value? Would it be sufficient just to print the EtherType in all cases? This could potentially be done using ether_type_print() if it is desirable to see the name, but that is a questionable problem to solve because nothing depends on the [per-packet] EtherType in this tag — the meaning for all packets is fixed in the DLT.

infrastation

Please address as noted, after that it should be easier to see if anything else requires attention before this is ready for merging.

infrastation added the DSA same as in libpcap label Nov 18, 2025

peteraxis force-pushed the master branch from e206950 to ddd8dd8 Compare December 3, 2025 14:21

Add MaxLinear GSW1xx DSA driver support

0cb20d7

For reading the packets in raw gsw1xx format.

peteraxis force-pushed the master branch from b64bad2 to 0cb20d7 Compare December 5, 2025 09:14

infrastation reviewed Dec 8, 2025

View reviewed changes

infrastation requested changes Dec 8, 2025

View reviewed changes

Add MaxLinear GSW1xx DSA driver support #1386

Are you sure you want to change the base?

Add MaxLinear GSW1xx DSA driver support #1386

Conversation

peteraxis commented Nov 13, 2025

Uh oh!

peteraxis commented Nov 13, 2025

Uh oh!

guyharris commented Nov 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

infrastation commented Nov 13, 2025

Uh oh!

peteraxis commented Nov 13, 2025

Uh oh!

peteraxis commented Nov 14, 2025

Uh oh!

guyharris commented Nov 14, 2025

Uh oh!

peteraxis commented Nov 14, 2025

Uh oh!

peteraxis commented Dec 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

infrastation Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

infrastation left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

guyharris commented Nov 13, 2025 •

edited

Loading

infrastation Dec 8, 2025 •

edited

Loading