> Thanks to Donald for his comments. This patch addresses the first of
> his two emails.
>
> This patch is _cumulative_ with the last one I sent (sundance 1.04), so
> do not discard that one.
>
> Again additional testing is appreciated. Keep the feedback coming,
> there will be more sundance bugfixes (patch #3, #4, etc.)
+ - If no phy is found, fail to load that board
+ - Always start phy id scan at id 1 to avoid problems (Donald Becker)
+ - Autodetect where mii_preable_required is needed,
+ default to not needed. (Donald Becker)
...
+
+/* Set iff a MII transceiver on any interface requires mdio preamble.
+ This only set with older tranceivers, so the extra
+ code size of a per-interface flag is not worthwhile. */
+static int mii_preamble_required = 0;
You can get rid of this as a module option, and make it a per-interface
setting.
The transceiver on the Kendin chip requires this (rather old-fashioned)
access method, while none of the previous Sundance-based boards with
external transceivers did.
I added it as a module parameter as a back-up over-ride, but I'm certain
that the automatic detection works.
This is a module parameter because I recently had a bad experience
with a specific 3Com 3c905B chip rev. It claimed to not need
transceiver preamble, but would not work without it.
> Theory of Operation
Whoever changed the transmit path should update the TOO.
- {"Sundance Technology Alta", {0x020113F0, 0xffffffff,},
- PCI_IOTYPE, 128, CanHaveMII},
+ {"D-Link DFE-550TX FAST Ethernet Adapter"},
+ {"D-Link DFE-550FX 100Mbps Fiber-optics Adapter"},
Yeah, you should probably throw away the rest of the changes.
You are probably going to want to keep the drv_flags field. I know
that all of the current chips have the same flag (CanHaveMII), but...
-- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/