netdev - Re: Please pull 'upstream-rtl8187' branch of wireless-2.6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 May 2007 13:23:40 +0200
From:	Michael Buesch <mb@...sch.de>
To:	Michael Wu <flamingice@...rmilk.net>
Cc:	Jeff Garzik <jeff@...zik.org>,
	"John W. Linville" <linville@...driver.com>,
	netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
	David Miller <davem@...emloft.net>
Subject: Re: Please pull 'upstream-rtl8187' branch of wireless-2.6

On Thursday 10 May 2007 04:16:22 Michael Wu wrote:
> > > +	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 numbers
> >
> I 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.

> > > +	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 delay
> >
> Most 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.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html