The WAN port (eth1) does not work on wrtsl54gs units using the 2.6.19 kernel. A previous forum post contains the symptoms... http://forum.openwrt.org/viewtopic.php?pid=45934
I dug into it today and confirmed that the 2.4 kernel variant of kamikaze does work on the unit. A little more digging at the b44 driver shows that it believes the eth0 phy address is 30 and the eth1 phy address is 5. The b44_phy_reset fails miserably on address 5. The 2.4 kernel uses address 30 for both eth0 and eth1. If, in the front of b44_phy_reset() you force bp->phy_addr to be 30 then both ethernet devices work.
I'm afraid I don't understand how this works, I was unable to find the datasheets for the underlying devices so all I can do is stab in the dark.
I have a suspicion that the reset is reseting the same phy twice and that the real eth1 phy might be somewhere else entirely but the default configuration happens to work. Or maybe not.
The mechanism for finding the phy address changed between the 2.4 and 2.6.19 kernels, probably leading to this problem.
The following patch works, but may be more invasive, for instance if anyone really does have a phy at 5 this will break them.
*** ./build_mipsel/linux-2.6-brcm47xx/linux-2.6.19.2/drivers/net/b44.c~ 2007-04-27 21:36:05.000000000 -0500
--- ./build_mipsel/linux-2.6-brcm47xx/linux-2.6.19.2/drivers/net/b44.c 2007-04-28 19:32:43.000000000 -0500
***************
*** 296,301 ****
--- 296,306 ----
u32 val;
int err;
+ /* hackish fix for wrtsl54gs, 5 fails, 30 works for eth1 */
+ if ( bp->phy_addr == 5) {
+ printk(KERN_INFO PFX "%s: Forcing PHY address to 30.\n", bp->dev->name);
+ bp->phy_addr = 30;
+ }
if (bp->phy_addr == B44_PHY_ADDR_NO_PHY)
return 0;
err = b44_writephy(bp, MII_BMCR, BMCR_RESET);