For those on lkml, I mistyped the address in the first mail. I just
did a second pass edit on the long debug session prompting this patch
fixed the cc to linux-kernel. So all those not on linux-pci should
be seeing that shortly, or one can look in mmotm.
On Jul 11, 2008, at 11:11 PM, Greg KH wrote:
Its not one driver, its more like 100 to 150.
Why is giving the driver the data it needs to support a card bad?
The debug session shows that not giving it the data it needs
is worse.
Worse, the kernel thinks it superior to the human and actively ignores
input with out even telling the user it did so.
The only argument I can come up with is if the data is a pointer, then
its likely that that root will not be able to find the correct value or
put it in a script that doesn't get updated on the next kernel install
and causes a crash. Root isn't likely to add driver data unless it
discovers that it is needed, so the existing default of passing 0
should remain.
If you want to argue that being able to tell the driver that it should
treat this card like card X is wrong, you should be arguing that the
whole notion of adding match table entries to the driver is wrong.
When it comes down to it, its the same thing. Yet, we support adding
ids today. The feature was added, and is used successfully with many
drivers. I'm trying to extend the population of drivers where it works
to include those that support more than one similar card but need to
know which one they are dealing with.
You left out:
I did the work to establish the scope of the problem.
So 3 drivers set the flag. 98 + 14 should set it immediately. The 27
that
use the value as a pointer probably can be re-written to use it as an
index. And
the hundreds of other drivers (I don't have the tree here to count)
apparently
don't care, as they most likely never look at that field. (I am
ingoring
conditional copiles that are not enabled by all-yes-config).
Obviously I disagree.
Since we added passing the id table entry to get the driver data from
the
table entry, we have close to 150 drivers that use it, instead of old
methods
such has hard coded lists of chips in case statements. Besides making
it easier
to maintain the driver, it actually improves the chances that the
driver can be
used on a new revision or subsystem id of the card.
But we have not been reviewing the setting of the flag with the use in
the driver.
A usage pattern of storing an index or flags has developed, and I claim
that the
flag now hurts more than it helps.
milton
--
