> I am at work but If I get home at a decent time I will test this patch.
>
> At home I have a file server with an ncr810 scsi controller. I had to patch the ncr driver to
> be able to use it on this machine because my bios does not set the master bit. This is an x86
> machine.
>
> In the AM53C974 driver I fould the following comment:
> /* PCI Spec 2.1 states that it is either the driver's or
> the PCI card's responsibility
> to set the PCI Master Enable Bit if needed.
> (from Mark Stockton <marks@schooner.sys.hou.compaq.com>) */
At least half of this comment is wrong, since PCI cards are required to
reset with this bit set to ZERO.
Can somebody tell me at what page of the PCI specs I can read the
remaining half?
Thanks.
In fact most of the PCI control register bits power on with ZERO. On
systems where the POST software does not do its work, the kernel has to do
some fix-ups in order to complete the PCI set-up. The most part of PCI
device configuration can be done in a _generic_ manner, so it is just
bloat and often broken to tamper too much PCI device configuration from
PCI device driver.
Device drivers have a knowledge of hardware that is most of the time
limited to the device family they are intended to drive. Most of the time,
it is more relevant to consider a missing PCI feature bit as the way POST
software and BIOSes work around broken hardware.
Note that I have no objection for adding this work-around into the driver,
at least as a boot command option. But for this patch, it is too late.
> So you can probably just remove the ifdef _powerpc_ around that piece of
> code since it does not seem to be architecture dependent at all and
> remove the code from ifdef _sparc_. This is not to much of a change for
> 2.2 is it? I am attaching that patch (diff -c).
Thanks for the patch, but allow me to do different.
(BTW, if I am ever provided with a patch that removes all PCI
configuration tampering from the driver, I will apply it immediately.) ;-)
> Earlier in the linux-kernel newsgroup we had a discussion around
> architecture dependant stuff in drivers and came to some conclusion that
> such code should probably go into drivers/pci/pci.c. This is of course a
> change for 2.3.
I agree it is the right place for this kind of tweaking. Doing at driver
level stuff that can be done in a generic manner by a central module is
just bloating the kernel.
> Is it feasibe to move the code architecture dependent code from the ncr
> driver and into pci.c. Code for setting master bit is already present in
> drivers/pci/pci.c: pci_set_master.
>
> The other stuff could be implemented as drivers/pci/pci.c: pci_set_io()
> pci_set_memory()
>
> The wacky ibm stuff should probably be inside some ifdef_powerpc_ fix
> section.
>
> The latency fix for sparc is probebly generic.
I have accepted the #ifdef __arch__ for PCI since I thought that things
will be handled properly later (and they don't), but each time I disagreed
with these patches.
> Well, I am no expert on the pci spec and I am sure hardware vendors
> break it all the time but since we have the generic drivers/pci/pci.c
> code we should probably use it and try to fix all architecture dependant
> stuff there. I know 2.0 does not have pci.c but I am still talking about
> 2.3 development and we could probably drop 2.0 support in new versions
> of the drivers when 2.2 is out.
I have updated a system from 1.2.13 to 2.0.35 two months ago.
Dropping 2.0 support is beyond question at the moment, and will probably
stay so for years in my humble opinion.
> The precense of pci.c probably calls for cleanup in lots of other
> drivers as well. We probably have lots of duplicated code trying to deal
> with generic pci specific stuff in more drivers.
There is always room for improvements in anything. We cannot do all the
needed changes at a time. But I hope, as you, that the 2.3 kernel will get
rid of all PCI configuration tweaks that are not needed, especially from
low-level drivers.
Regards,
Gerard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/