PlayStation 2 SMAP Ethernet driver

[hubix94]

Staging pull request inside my own fork - not aimed at frno7/linux. Opened here so the diff can be read without touching upstream.

Base is ps2-dev9-power-up, not ps2-main, and that is deliberate: the driver refuses to load on a kernel whose iop-dev9 does not power the expansion bay. Built on plain ps2-main it fails with

ps2-smap: expansion bay is not powered (DEV9 power 0000); this needs a kernel whose iop-dev9 initialises the bay

so this work sits on top of the two DEV9 fixes.

What it does

• net: ps2: Add PlayStation 2 SMAP Ethernet driver - drivers/net/ethernet/ps2/ with its own Kconfig and Makefile, wired into drivers/net/ethernet/{Kconfig,Makefile}. EE-side port of Sony's linux-2.4.17/drivers/ps2/smap.c (GPL v2) onto 5.4: net_device_ops, NAPI, phylib with its own MDIO bus, MAC read from the EEPROM. Programmed I/O through a bounce buffer; the IOP-side DMA of the original is not ported.
• MIPS: PS2: Register the SMAP Ethernet device - the platform device the driver binds to, plus CONFIG_PS2_SMAP=m in ps2_defconfig.

The chip window is shared with the ATA registers at IOP_PATA_BASE, so the 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

Hardware results

SCPH-30004 (PAL, ROM 0150), adapter in the expansion bay, same driver source built out of tree:

Transmit	2.4 MB/s (~19 Mbit/s), sustained over 300 MB
Receive	1.4 MB/s (~11 Mbit/s)
Interrupts	~240k TXEND over the 300 MB run, no stall, no fallback to polling
Module reload	works without a reboot
pata_ps2 loaded at the same time	no interference, throughput unchanged

Known gaps

• No DMA. That is what the throughput figures cost.
• Only tested on SCPH-30004. Nothing in the driver is model-aware; SCPH-700xx is untested.
• The in-tree wiring is being verified now. The driver code is the tested one; binding through platform resources is what this branch changes.
• checkpatch reports 0 errors and 47 style warnings, mostly networking block-comment style and long lines.

🤖 Generated with Claude Code

[hubix94]

Verified on hardware. Cold boot from this branch on an SCPH-30004:

dev9: Expansion device power on
dev9: Interface initialized
ps2-smap ps2-smap eth0: PlayStation 2 SMAP at 14000000, SPEED rev1 0011 rev3 0003, MAC 00:04:1f:2e:37:1c, irqs 115/114/116
ps2-smap ps2-smap eth0: Link is Up - 100Mbps/Full - flow control off

The module is in-tree - /proc/modules shows ps2_smap without the (O) taint - and the resources come out disjoint from the ATA window:

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

30 MB transmit in 14.0 s (2.25 MB/s), matching the out-of-tree build, with no SPEED interrupts stopped and no fallback to polling. The console takes a DHCP lease and starts SSH about 20 s into the boot without any manual step.

Two things this branch got wrong before it worked, both worth recording:

1. The first version declared the whole 16 KiB chip window as one resource, which collides with the ATA device registered earlier in devices.c. The SMAP platform device then never registers and platform_driver_probe() has nothing to bind to.
2. It was based on ps2-main, where iop_dev9_init() returns before exp_dev_init(). The bay stays unpowered and the driver refuses to load - correctly, and with a message that says so. Hence the base branch here.