Patch to add VIA PCI quirk for Enhanced/Extended USB on VT8235
southbridge. It is needed in order to use EHCI/USB 2.0 with ACPI.
Without it IRQs are not routed correctly, you get an "Unlink after
no-IRQ?" error and the device is unusable.
I belive this could also be a fix for Bugzilla Bug 5835.
Signed-off-by: Mark Hindley <mark@hindley.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
- add the ICH6(R) LPC to the ICH6 ACPI quirks. currently only the ICH6-M
is handled. [ PCI_DEVICE_ID_INTEL_ICH6_1 is the ICH6-M LPC, ICH6_0 is
the ICH6(R) ]
- remove the wrong quirk calling asus_hides_smbus_lpc() for ICH6. the
register modified in asus_hides_smbus_lpc() has a different meaning in
ICH6.
Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Unhide the SMBus controller on the Asus PU-DLS board.
This fixes bug #6763.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Without this quirk, e100 can be pulling on a shared
interrupt line when another device (eg. USB) loads,
causing the interrupt to scream and get disabled.
http://bugzilla.kernel.org/show_bug.cgi?id=5918
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
When changing power states from D0->DX and then from DX->D0, some
Intel PCIE chipsets will cause a device reset to occur. This will
cause problems for any D State other than D3, since any state
information that the driver will expect to be present coming from
a D1 or D2 state will have been cleared. This patch addes a
flag to the pci_dev structure to indicate that devices should
not use states D1 or D2, and will set that flag for the affected
chipsets. This patch also modifies pci_set_power_state() so that
when a device driver tries to set the power state on
a device that is downstream from an affected chipset, or on one
of the affected devices it only allows state changes to or
from D0 & D3. In addition, this patch allows the delay time
between D3->D0 to be changed via a quirk. These chipsets also
need additional time to change states beyond the normal 10ms.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Some VIA southbridges contain a flag in the ACPI register space that
indicates whether an abnormal poweroff has occured, presumably with the
intention that it can be cleared on clean shutdown. Some BIOSes check this
flag at resume time, and will re-POST the system rather than jump back to
the OS if it's set. Clearing it at boot time appears to be sufficient.
I'm not sure if drivers/pci/quirks.c is the right place to do it, but I'm
not sure where would be cleaner.
[akpm@osdl.org: cleanups, build fix]
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Greg KH <greg@kroah.com>
Cc: "Brown, Len" <len.brown@intel.com>
Cc: "Yu, Luming" <luming.yu@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Prior to 2.6.18rc1 you could install with devices on a JMicron chipset
using the "all-generic-ide" option. As of this kernel the AHCI driver
grabs the controller and rams it into AHCI mode losing the PATA ports
and making CD drives and the like vanish. The all-generic-ide option
fails because the AHCI driver grabbed the PCI device and reconfigured
it.
To fix this three things are needed.
#1 We must put the chip into dual function mode
#2 The AHCI driver must grab only function 0 (already in your rc1 tree)
#3 Something must grab the PATA ports
The attached patch is the minimal risk edition of this. It puts the chip
into dual function mode so that AHCI will grab the SATA ports without
losing the PATA ports. To keep the risk as low as possible the third
patch adds the PCI identifiers for the PATA port and the FN check to the
ide-generic driver. There is a more featured jmicron driver on its way
but that adds risk and the ide-generic support is sufficient to install
and run a system.
The actual chip setup done by the quirk is the precise setup recommended
by the vendor.
(The JMB368 appears only in the ide-generic entry as it has no AHCI so
does not need the quirk)
Signed-off-by: Alan Cox <alan@redhat.com>
Acked-by: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This is confirmed to fix a hang due to PCI resource conflicts with
setting up the Cardbus bridge on old laptops with the 440MX chipsets.
Original report by Alessio Sangalli, lspci debugging help by Pekka
Enberg, and trial patch suggested by Daniel Ritz:
"From the docs available i would _guess_ this thing is really similar
to the 82443BX/82371AB combination. at least the SMBus base address
register is hidden at the very same place (32bit at 0x90 in function
3 of the "south" brigde)"
The dang thing is largely undocumented, but the patch was corroborated
by Asit Mallick:
"I am trying to find the register information. 440MX is an integration of
440BX north-bridge without AGP and PIIX4E (82371EB). PIIX4 quirk
should cover the ACPI and SMBus related I/O registers."
and verified to fix the problem by Alessio.
Cc: Daniel Ritz <daniel.ritz-ml@swissonline.ch>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Dmitry Torokhov <dtor_core@ameritech.net>
Tested-by: Alessio Sangalli <alesan@manoweb.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The nVidia CK804 PCI-E chipset supports the AER extended capability
but sometimes fails to link it (with some BIOS or after a warm reboot).
It makes the AER cap invisible to pci_find_ext_capability().
The patch adds a quirk to set the missing bit that controls the
linking of the capability.
By the way, it removes the corresponding code in the myri10ge driver.
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: Loic Prylli <loic@myri.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Be more selective when running the MSI-K8T-Neo2Fir soundcard PCI quirk so
as not to run this on hardware where it's probably not needed.
Signed-off-by: Chris Wedgwood <cw@f00f.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Currently, the EDAC (error detection and correction) modules that are in
the kernel contain some features that need to be moved. After some good
feedback on the PCI Parity detection code and interface
(http://www.ussg.iu.edu/hypermail/linux/kernel/0603.1/0897.html) this
patch ADDs an new attribute to the pci_dev structure: Namely the
'broken_parity_status' bit.
When set this indicates that the respective hardware generates false
positives of Parity errors.
The EDAC "blacklist" solution was inferior and will be removed in a
future patch.
Also in this patch is a PCI quirk.c entry for an Infiniband PCI-X card
which generates false positive parity errors.
I am requesting comments on this AND on the possibility of a exposing
this 'broken_parity_status' bit to userland via the PCI device sysfs
directory for devices. This access would allow for enabling of this
feature on new devices and for old devices that have their drivers
updated. (SLES 9 SP3 did this on an ATI motherboard video device). There
is a need to update such a PCI attribute between kernel releases.
This patch just adds a storage place for the attribute and a quirk entry
for a known bad PCI device. PCI Parity reaper/harvestor operations are
in EDAC itself and will be refactored to use this PCI attribute instead
of its own mechanisms (which are currently disabled) in the future.
Signed-off-by: Doug Thompson <norsk5@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Do not enable the SMBus device on Asus boards if suspend is used. We do
not reenable the device on resume, leading to all sorts of undesirable
effects, the worst being a total fan failure after resume on Samsung P35
laptop.
Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Signed-off-by: Pavel Machek <pavel@suse.cz>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
An earlier commit (75cf7456dd) changed an
overly-zealous PCI quirk to only poke those VIA devices that need it.
However, some PCI devices were not included in what I hope is now the full
list. Consequently we're failing to run the quirk on all machines which need
it, causing IRQ routing failures.
This should I hope correct this.
Thanks to Masoud Sharbiani <masouds@masoud.ir> for pointing this out
and testing the fix.
Signed-off-by: Chris Wedgwood <cw@f00f.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Alan Cox pointed out that the VIA 'IRQ fixup' was erroneously running
on my system which has no VIA southbridge (but I do have a VIA IEEE
1394 device).
This should address that. I also changed "Via IRQ" to "VIA IRQ"
(initially I read Via as a capitalized via (by way/means of).
Signed-off-by: Chris Wedgwood <cw@f00f.org>
Acked-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On the MSI-K8T-NEO2 FIR ( Athlon-64, Socket 939 with VIA-K8T800- Chipset
and onboard Sound,... ) the BIOS lets you choose "DISABLED" or "AUTO" for
the On-Board Sound Device.
If you add another PCI-Sound-Card the BIOS disables the on-board device.
So far I have a Quirk, that does set the correspondent BIT in the
PCI-registers to enable the soundcard.
But how to ensure that the code is executed ONLY on excactly this kind of
boards (not any other with similar Chipset)?
Cc: Jaroslav Kysela <perex@suse.cz>
Acked-by: Takashi Iwai <tiwai@suse.de>
Cc: Lee Revell <rlrevell@joe-job.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The Asus A6VA notebook was reported to need a PCI quirk to unhide
the SMBus.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The naming of the constant defined for PCI ID 1022:7450 does not seem
to match the information at http://pciids.sourceforge.net/:
http://pci-ids.ucw.cz/iii/?i=1022
There 1022:7450 is listed as "AMD-8131 PCI-X Bridge" while 1022:7451
is listed as "AMD-8131 PCI-X IOAPIC". Yet, the current definition for
0x7450 is PCI_DEVICE_ID_AMD_8131_APIC. It seems to me like that name
should map to 0x7451, while a name like PCI_DEVICE_ID_AMD_8131_BRIDGE
should map to 0x7450.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
It turns out AMD 8131 quirk only affects MSI for devices behind the 8131 bridge.
Handle this by adding a flags field in pci_bus, inherited from parent to child.
Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On ASUS A8V and A8V Deluxe boards, the onboard AC97 audio controller
and MC97 modem controller are deactivated when a second PCI soundcard
is present. This patch enables them.
Signed-off-by: Bauke Jan Douma <bjdouma@xs4all.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I attach a trivial patch for 2.6.15.4 that unhides SMBus controller
on an HP Compaq nx6110 notebook.
Signed-off-by: Tomasz Koprowski <tomek@koprowski.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The IBM Dock II cardbus bridges require some extra configuration
before Yenta is loaded in order to setup the Interrupts to be
routed properly.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I've implemented a quirk to take advantage of the 1KB I/O space
granularity option on the Intel P64H2 PCI Bridge. I had to change
probe.c because it sets the resource start and end to be aligned on 4k
boundaries (after the quirk sets them to 1k boundaries). I've tested
this patch on a Unisys ES7000-600 both with and without the 1KB option
enabled. I also tested this on a 2 processor Dell box that doesn't have
a P64H2 to make sure there were no negative affects there.
Signed-off-by: Dan Yeisley <dan.yeisley@unisys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Combined mode sucks. Especially when both libata and the legacy IDE
drivers try to drive ports on the same device, since that makes DMA
rather difficult.
This patch addresses the problem by allowing the user to control which
driver binds to the ports in a combined mode configuration. In many
cases, they'll probably want the libata driver to control both ports
since it can use DMA for talking with ATAPI devices (when
libata.atapi_enabled=1 of course). It also allows the user to get old
school behavior by letting the legacy IDE driver bind to both ports.
But neither is forced, the patch doesn't change current behavior unless
one of combined_mode=ide or combined_mode=libata is passed
on the boot line. Either of those options may require you to access
your devices via different device nodes (/dev/hd* in the ide case
and /dev/sd* in the libata case), though of course if you have udev
installed nicely you may not notice anything. :)
Let me know if the documentation is too cryptic, I'd be happy to expand
on it if necessary. I think most users will want to boot with
'combined_mode=libata' and add 'options libata atapi_enabled=1'
to their modules.conf to get good DVD playing and disk behavior
(haven't tested CD or DVD writing though).
I'd much rather things behave sanely by default (i.e. DMA for devices on
both ports), but apparently that's difficult given the various chip
bugs and hardware configs out there (not to mention that people's
drives may suddenly change from /dev/hdc to /dev/sdb), so this boot
option may be the correct long term fix.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Move the PPC fixup for old NCR 810 controllers to generic quirks -
it's needed for Alpha, x86 and other architectures that use
setup-bus.c.
Thanks to Jay Estabrook for pointing out the issue.
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The quirk names for VIA 686 are mistyped in 2.6.14 (686 vs 868). S3 868
influence? :) Here is a patch to correct them.
Signed-off-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This moves the PCI quirk handling for USB host controllers from the
PCI directory to the USB directory. Follow-on patches will need to:
(a) merge these copies with the originals in the HCD reset methods.
they don't wholly agree, despite doing the very same thing; and
(b) eventually change it so "usb-handoff" is the default, to help
get more robust USB/BIOS/input/... interactions.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/Makefile | 2
drivers/pci/quirks.c | 253 ---------------------------------------
drivers/usb/Makefile | 1
drivers/usb/host/Makefile | 5
drivers/usb/host/pci-quirks.c | 272 ++++++++++++++++++++++++++++++++++++++++++
5 files changed, 280 insertions(+), 253 deletions(-)
One more SMBus unhiding quirk, this time for the HP D530. Requested and
successfully tested by Ben Cranston.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch unhides hidden SMBus on ICH6 chipset installed in
Asus M6V notebook. I would like to thank Michal Mleczko for
testing and help.
Signed-Off-By: Rudolf Marek <r.marek@sh.cvut.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/pci/quirks.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
This patch just adds ACPI and GPIO regions to its LPC bridge, similar
way as ICH4 did. I would like to thank Michal Mleczko for testing.
Signed-off-by: Rudolf Marek <r.marek@sh.cvut.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/pci/quirks.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
When reserving an PCI quirk, note that in the kernel bootup messages.
Also, parse the strange PIIX4 device resources - they should get their
own PCI resource quirks, but for now just print out what it finds to
verify that the code does the right thing.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This change makes quirk_intel_ide_combined() dependent on the precise
conditions under which it is needed:
* IDE is built in
* IDE SATA option is not set
* ata_piix or ahci drivers are enabled
This fixes an issue where some modular configurations would not cause
the quirk to be enabled.
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Linus torvalds <torvalds@osdl.org>
Trivial patch against 2.6.13 to unhide SMBus on Compaq Evo N620c laptop using
Intel 82855PM chipset.
Signed-off-by: Rumen Zarev <rzarev@caltech.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There were three changes necessary in order to allow
sparc64 to use setup-res.c:
1) Sparc64 roots the PCI I/O and MEM address space using
parent resources contained in the PCI controller structure.
I'm actually surprised no other platforms do this, especially
ones like Alpha and PPC{,64}. These resources get linked into the
iomem/ioport tree when PCI controllers are probed.
So the hierarchy looks like this:
iomem --|
PCI controller 1 MEM space --|
device 1
device 2
etc.
PCI controller 2 MEM space --|
...
ioport --|
PCI controller 1 IO space --|
...
PCI controller 2 IO space --|
...
You get the idea. The drivers/pci/setup-res.c code allocates
using plain iomem_space and ioport_space as the root, so that
wouldn't work with the above setup.
So I added a pcibios_select_root() that is used to handle this.
It uses the PCI controller struct's io_space and mem_space on
sparc64, and io{port,mem}_resource on every other platform to
keep current behavior.
2) quirk_io_region() is buggy. It takes in raw BUS view addresses
and tries to use them as a PCI resource.
pci_claim_resource() expects the resource to be fully formed when
it gets called. The sparc64 implementation would do the translation
but that's absolutely wrong, because if the same resource gets
released then re-claimed we'll adjust things twice.
So I fixed up quirk_io_region() to do the proper pcibios_bus_to_resource()
conversion before passing it on to pci_claim_resource().
3) I was mistakedly __init'ing the function methods the PCI controller
drivers provide on sparc64 to implement some parts of these
routines. This was, of course, easy to fix.
So we end up with the following, and that nasty SPARC64 makefile
ifdef in drivers/pci/Makefile is finally zapped.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The VIA VT8237's IOAPIC sends 'APIC De-Assert Messages' by default, causing
another CPU interrupt when the IRQ pin is de-asserted. This feature is
switched off by the patch to get rid of doubled ioapic level interrupt
rates.
Signed-off-by: Karsten Wiese <annabellesgarden@yahoo.de>
Tested-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
On the 6700/6702 PXH part, a MSI may get corrupted if an ACPI hotplug
driver and SHPC driver in MSI mode are used together.
This patch will prevent MSI from being enabled for the SHPC as part of
an early pci quirk, as well as on any pci device which sets the no_msi
bit.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Like many other southbridges from different manufacturers, VIA VT8235
chip has two non-standard BARs for power management and SMBus registers
(see the datasheet at http://www.via.com.tw).
This new quirk routine fixes boot problem with 2.6.13-rc2/rc6 kernels on
Targa Visionary 811 Athlon64 laptop, as reported by Mikael Pettersson
<mikpe@csd.uu.se>.
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
One more Asus motherboard requiring the SMBus quirk (P4B-LX). Original
patch from Salah Coronya.
Signed-off-by: Salah Coronya <salahx@yahoo.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
MSI functionality is broken on the GC_LE x86 chipset that Serverworks
developed and that is being used in various platforms today. Broadcom is
going to push out to the kernel MSI enabled Gigabit drivers (in the very
near future), and we would like to make sure that MSI does not get
enabled on any platforms using the GC_LE chipset (device id 0x17).
Following the AMD 8131 example, I am including a patch to disable MSI
functionality when a GCNB_LE is detected. Please let me know if there
are any issues with this. This is a permanent fix for this chipset, as
the hardware will not be updated.
Signed-off-by: Narendra Sankar <nsankar@broadcom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
At least some VIA chipsets require the fixup even in IO-APIC mode.
This was found and debugged with the patient assistance of Stian
Jordet <liste@jordet.nu> on an Asus CUV266-DLS motherboard.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Delete quirk_via_bridge(), restore quirk_via_irqpic() -- but now
improved to be invoked upon device ENABLE, and now only for VIA devices
-- not all devices behind VIA bridges.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch just adds Intel's Hance Rapid south bridge IDs to ICH4 region quirk.
Patch was successfuly tested by Chunhao Huang from Winbond.
Signed-Off-By: Rudolf Marek <r.marek@sh.cvut.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds the Intel ESB2 DID's to the ata_piix.c and quirks.c file for
IDE mode SATA support.
Signed-off-by: Jason Gaston <Jason.d.gaston@intel.com>
Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Mark Hindley