Fix 8139too ring size for dreamcast/embedded
PATCH 1/1 Fix 8139too ring size for dreamcast/embedded
Presently 2.6.6 backs out the CONFIG_8139_RXBUF_IDX in favor of using a hardcoded 8139_RXBUF_IDX (again). This seems to have been done due to some issues occuring with 8139_RXBUF_IDX == 3, however (as the Kconfig pointed out), we still need 8139_RXBUF_IDX == 1 in the CONFIG_SH_DREAMCAST case.
The patch which made this change can be seen at:
Before that, CONFIG_8139_RXBUF_IDX was set to 1 both in the CONFIG_SH_DREAMCAST and CONFIG_EMBEDDED cases. This patch adds that back into the current 8139too.
Additionally, why remove the config option at all? Wouldn't it just be easier to drop the range from 0 - 3 to 0 - 2 until problems with a 64K ring size are resolved?
drivers/net/8139too.c renamed from drivers/net/8139too.c.orig +4 -0
@@ -171,7 +171,11 @@* Receive ring size * Warning: 64K ring has hardware issues and may lock up. */ +#if defined(CONFIG_SH_DREAMCAST ) || defined(CONFIG_EMBEDDED ) +#define RX_BUF_IDX 1/* 16K ring */ +#else #define RX_BUF_IDX 2/* 32K ring */ +#endif #define RX_BUF_LEN (8192 << RX_BUF_IDX)#define RX_BUF_PAD 16#define RX_BUF_WRAP_PAD 2048/* spare padding to handle lack of packet wrap */
Quoted 6 lines · Paul Mundt
Presently 2.6.6 backs out the
CONFIG_8139_RXBUF_IDXin favor of using a hardcoded 8139_RXBUF_IDX (again). This seems to have been done due to some issues occuring with 8139_RXBUF_IDX == 3, however (as theKconfigpointed out), we still need 8139_RXBUF_IDX == 1 in theCONFIG_SH_DREAMCASTcase.
Quoted 6 lines
The patch which made this change can be seen at:
Before that,
CONFIG_8139_RXBUF_IDXwas set to 1 both in theCONFIG_SH_DREAMCASTandCONFIG_EMBEDDEDcases. This patch adds that back into the current 8139too.
Patch applied to 2.6.x.
Quoted 3 lines
Additionally, why remove the config option at all? Wouldn't it just be easier to drop the range from 0 - 3 to 0 - 2 until problems with a 64K ring size are resolved?
<shrug> Mainly it was easier just to hardcode it in the driver.
I would not object to your suggestion of "0 - 2", however I tend to think that the current lack of option, with your patch applied, serves the user best: the driver will always use the largest RX buffer possible for the hardware.
Jeff