Re: Please pull 'upstream-rtl8187' branch of wireless-2.6
From: Michael Buesch <hidden>
Date: 2007-05-10 11:23:40
Also in:
linux-wireless
On Thursday 10 May 2007 04:16:22 Michael Wu wrote:
quoted
quoted
+ rtl818x_iowrite8(priv, (u8 *)0xFE18, 0x10); + rtl818x_iowrite8(priv, (u8 *)0xFE18, 0x11); + rtl818x_iowrite8(priv, (u8 *)0xFE18, 0x00); + mdelay(200);ditto also, kill the magic numbersI have no idea what that does so I don't see the point in moving the number to some define. However, the hardware does seem to work okay without this part so I can remove it if you bothers you so much.
Nah, Jeff. Please don't go this path. If we have to remove all magic numbers from drivers, we'd have to either *) Drop reverse engineered drivers like bcm43xx completely. *) Clutter them with completely useless defines such as #define RADIO_UNKNOWN97A_REG 0x97A Better leave such magic registers/values in the code as-is and probably convert them to good defines later, if reverse engineering found out the meaning. That's what I'm doing for bcm43xx and it makes a _whole_ lot more sense.
quoted
quoted
+ if (eeprom->reg_data_in) + reg |= RTL818X_EEPROM_CMD_WRITE; + if (eeprom->reg_data_out) + reg |= RTL818X_EEPROM_CMD_READ; + if (eeprom->reg_data_clock) + reg |= RTL818X_EEPROM_CMD_CK; + if (eeprom->reg_chip_select) + reg |= RTL818X_EEPROM_CMD_CS; + + rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD, reg); + udelay(10);questionable delayMost likely to prevent hitting the eeprom too fast.
Accessing eeproms is almost always some kind of critical and timing dependent task on every device. That's because of the electrical behavior of the eeprom and its bus. -- Greetings Michael.