net: ps2: PlayStation 2 SMAP Ethernet driver

[hubix94]

Follow-up to #94, as agreed there. The two DEV9 fixes come back as part of the
work they were written for, with the network driver on top.

What this is

An EE-side port of Sony's linux-2.4.17/drivers/ps2/smap.c (GPL v2, taken from
the BlackRhino kit, cross-checked against the 2.2.1 driver on the PlayStation 2
Linux DISC2) onto 5.4. Sony's are the register layout, the FIFO and
buffer-descriptor protocol, the EMAC3 default values and the EEPROM bit-bang
sequence. New for 5.4 is the structure: net_device_ops, NAPI, phylib with its
own MDIO bus instead of the original link-check thread, and
netdev_alloc_skb_ip_align().

Five commits:

Commit
MIPS: PS2: IOP: Fix iop_write{b,w,l}() issuing the LOADFILE read RPC	the typo you called a valid fix in #94
MIPS: PS2: IOP: Actually initialise the DEV9 expansion bay	removes the early return that left exp_dev_init() as dead code
net: ps2: Add PlayStation 2 SMAP Ethernet driver	drivers/net/ethernet/ps2/, own Kconfig and Makefile
MIPS: PS2: Register the SMAP Ethernet device	the platform device it binds to, CONFIG_PS2_SMAP=m in ps2_defconfig
net: ps2: Close the interface on machine shutdown	.shutdown; without it, resetting the IOP panics the kernel in the driver's timer

The chip window is shared with the ATA registers, so the platform device
declares the two ranges SMAP actually uses rather than the whole window.
Claiming all of it collides with the ATA device registered a few lines earlier,
and the SMAP device then never registers at all. On hardware:

14000000-1400003f : speed
14000040-1400005f : PATA
14000100-14003fff : smap

Measured on hardware

SCPH-30004 (PAL, ROM 0150), Network Adaptor in the expansion bay, over TCP with
SSH on top, so the figures include encryption on the same CPU:

Transmit	2.32 MB/s (~18.5 Mbit/s), 30 MB in 13.5 s
Receive	1.41 MB/s (~11 Mbit/s), 30 MB in 22.3 s
Interrupts over those 60 MB	24817 TXEND, 16254 RXEND, 0 EMAC3, no stall, no fallback to polling
Interface counters after it	rx_errors 0 tx_errors 0, and on close: 29115 rx, 26504 tx, 41402 interrupts, 30539 dnv cleared, ran on interrupts
Longest run	367 MB over 19 minutes, 0 interface errors
Module reload	rmmod + insmod works without rebooting the console
modprobe pata_ps2 with the network up	ata1: PATA max UDMA/66 irq 110, network untouched, 2.23 MB/s against 2.32 without it
Cold boot from the kernel image	DHCP lease and sshd at 20 s from kernel start, no keyboard involved

The transmit, receive, reload and interrupt figures above were re-measured on
exactly the commits in this branch. The 367 MB run and the pata_ps2 test are
from a build a day older whose driver differs only in comment wrapping.

Two details from that testing that may be worth knowing regardless of this
driver's fate:

• ata.irx finds the bay already powered by iop-dev9 (power is already on)
  and skips its own sequence, and the interrupts are disjoint - 110 for ATA
  against 114/115/116 for SMAP. That is why the two coexist.
• poweroff -f still works with the bay powered on, at least on this model.
  reboot / halt / shutdown support #67 suggested it might not.

On your comments in #94

An IOP counterpart: agreed, and not written yet. This is the EE-only
prototype you called a good starting point, and everything it does over the SIF
is a candidate to move to the IOP later - DEV9 initialisation the way ata.c
does it, interrupt handling, and eventually DMA, which is what the throughput
figures above are really costing.

Retiring drivers/ps2/iop-dev9.c: yes, once the IOP module exists. The
driver needs the bay powered before it touches the register window; today
iop-dev9 is the only thing in the tree that does it at boot. A smap.irx with
its own dev9_init() would take that over and the file could go. Until then the
second commit here keeps it working rather than deepening the dependency - it
deletes a return 0;, nothing more.

The interrupt relay. Understood, and it matches what the driver ran into:
with no irq_mask/irq_unmask in iop-irq.c the driver cannot mask its own
source for the duration of a NAPI poll, so it acknowledges through
SMAP_INTR_CLR and relies on the IOP re-arming. It works, and one thing that
surprised me is worth recording: the IOP clears only STAT & MASK, so the
TXDNV/RXDNV bits - which are not in its mask - stay set and hold the line
high. Clearing them from the EE is what took this driver from dying under load
to surviving 367 MB. Over that run they were set 258323 times.

Known gaps

• No DMA. Sony's driver moved data with SmapDmaWrite/SmapDmaRead on the
  IOP side; this one does 32-bit PIO from the EE through a bounce buffer,
  because skb data is only 2-byte aligned.
• Only tested on SCPH-30004. Nothing is model-aware: the PHY is hardwired to
  MDIO address 1 and the register map is the adapter's. SCPH-700xx is untested.
  Probe does refuse cleanly on unexpected hardware - it bails out if SPEED
  rev1 reads 0000/ffff, or if rev3 lacks the SMAP capability bit.
• No multicast filter. The first group switches the interface to
  all-multicast, as the original did.
• rx_dropped is not zero, and it rises only where
  netdev_alloc_skb_ip_align() fails, so it is memory pressure on a 32 MB
  machine rather than a data-path fault. Under traffic it is small - 60 frames
  out of 28529 received, 0.2% - but it is much worse during boot, 101 out of the
  first 226 frames, when the machine is down to 9 MB free. A receive path that
  recycled buffers instead of allocating one per frame would not care.
• A polling fallback is still in the driver, behind the poll module
  parameter. It was written when the relay had never delivered a SPEED interrupt
  to the EE and an interrupt-only driver would have said nothing about whether
  the data path worked. Since the TXDNV fix it has not been needed. Happy to
  remove it if you would rather not carry it.

checkpatch

0 errors and nothing about line length. What is left is 32 of "networking block
comments don't use an empty /* line" - the rest of this tree,
drivers/ps2/iop-dev9.c and drivers/ata/pata_ps2.c included, uses the
ordinary kernel comment style, so I matched the tree rather than the netdev
rule. Say which you would prefer and I will convert them. Sixteen lines still
run past 80 columns, all of them log messages that
Documentation/process/coding-style.rst says not to break.

Provenance

Sony's code is GPL v2 and the file records where each part came from, with the
2.4.17 line numbers for the parts that are ports rather than rewrites.
MODULE_AUTHOR credits Sony alongside me. As in #94, the commits carry
Co-Authored-By for the AI assistance I use, and the caveat from my first
message stands: treat the measurements as solid and anything I say about causes
as a suggestion that may be wrong.

🤖 Generated with Claude Code

[hubix94]

Closed in favour of #96. The commits needed their authorship metadata corrected, and that changes every commit ID, so opening a fresh pull request was cleaner than force-pushing under this one. Same code and same measurements - the only difference is a dropped copyright line, since the driver is a port of Sony's. Sorry for the noise.