On Tue, 22 Jan 2008 04:56:11 -0500
No, sorry Jeff.  I simply took the vendor's current driver and matched

his initialization settings.  I can only assume he discovered these

values through lab testing.
For this and the other "conform to vendor driver" patches in this set, I

thought it important to have the in-tree driver match the vendor driver

as closely as possible.  The primary motivations are (1) my belief that

he's in a better position to test the NIC, and (2) to be able to go to

him for assistance occasionally and not be rejected because of

significant differences between his and our drivers.
Jay

--

I don't think we should be doing this without justification.  From all the atl1

and atl2 code I've looked at, I've gotten the impression that their driver

development processes are extremely ad-hoc.  There is code in the Atheros

version of atl2 that cannot *possibly* apply to that hardware and was just

copied and pasted from atl1, just as much of atl1 was copied and pasted from

e1000.  The fact that various versions have different magic numbers may simply

mean they copied and pasted from different irrelevant and incorrect sources.
Our contacts at Atheros seem to be very good electrical engineers, so when they

tell us that a certain setting should be changed to match particular properties

of the hardware, I trust them.  They are not, however, experienced and

disciplined kernel developers, so absent such justification I think we should

stick with what we have, which has been improved and reviewed by people who

*are* experienced and disciplined kernel developers.
We have at least as much to teach Atheros about writing kernel code as they have

to teach us about their hardware.
	-- Chris

--

Since these changes are not simply moving code around, we really do need

full explanations for them, and to understand their need.
Blindly copying code from an exterior driver is pointless, and no way at

all to run an engineering process.
If the driver is not going to get the review and attention necessary,

bug fixes and feedback attended-to, then there's not much point in

having this driver in the kernel at all.
You will only lead yourself to frustration, if you set up a system where

changes only flow one way.  That's not how Linux development is done at all.
	Jeff
--