Add gsw1xx htdocs

[peteraxis]

This is for the pull req on libpcap and tcpdump regarding gsw1xx.

[infrastation]

Thank you for preparing this. I had a look at the changes and the GSW145 datasheet rev. 1.4 and the following caught my eye:

• The document never uses the term "EDSA" and calls the tag "Special Tag", is there a good reason to say "EDSA"?
• The document describes one more tag format — "Special Tag Egress Internal Format (without EtherType)" — which uses all 8 bytes for Special Tag Content and, as far as the document says it, is a matter of hardware port configuration (i.e. it is not possible to tell an EtherType'd egress tag from a non-EtherType'd egress tag using the 8 bytes), and both formats can appear on the CPU port, correct? Is there any provision in the Linux driver to make sure the non-EtherType'd variety never comes to the CPU? This deserves at least some clarification.
• Is there any possibility the GSW1xx tag will ever appear in a different part of the frame or be a part of some other DLT other than this new one? If not, then it may make more sense to define the structure using one HTML page rather than two.

[peteraxis]

1 EDSA make sense too me in the context of Linux. It is implemented as a DSA driver and use 8 byte header. But Special-Tag should be used too.
2 I do not think there is a way with current firmware configuration. https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=22335939ec907cca26be41f10f6cc01f0df8b0e9 uses as static gsw1xx_pce_microcode. But that is a limitation and does not fit the DSA framework to be changed and no devicetree properties either.
3 Not intentionally, I think that will break the driver. However that is a Linux context. This sock can be used on other systems.

I will update for 1&3 but Im not sure what to do with 2.

[infrastation]

(1) - There is already DLT_DSA_TAG_EDSA, so it is desirable to avoid accidental confusion.

(2) and (3) - It is conceivable that some other firmware/configuration will use the "internal egress format" (non-EtherType'd) for the switch->CPU frames and the "ingress" (EtherType'd) format for CPU->switch frames. Specific reasons for that are not in scope of this allocation, but in case that occurs at a later point, it would make the most sense to declare that a different DSA tag, as far as Linux reports it for an interface, and a different DLT. In that case it would make sense to have a separate page for the 6-octet "Special Tag Content", and to put the first two octets into respective DLTs, where in this new DLT they would mean the programmable EtherType and in the other potential future DLT they would mean the various contents of that other DLT. However, until (and if) that becomes necessary, it would be fine to keep it one page, and to say that this new DLT represents only the case when the hardware is configured to use "ingress" and "egress external format", which means all frames are always EtherType'd in both directions.