linux-kernel - Re: via irq quirk breakage

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:	Tue, 30 Jan 2007 14:47:01 +0300
From:	Sergey Vlasov <vsu@...linux.ru>
To:	Jean Delvare <jdelvare@...e.de>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Daniel Drake <dsd@...ctivated.net>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Adrian Bunk <bunk@...sta.de>
Subject: Re: via irq quirk breakage

On Tue, 30 Jan 2007 08:54:05 +0100 Jean Delvare wrote:

> You have an old VT82C686 south bridge, which was tagged as "special" by
> Alan. For this chip, Alan's code only allows devices 00:00.x to be quirked.
> As my code was merely a reimplementation of Alan's idea, it does the same.
> Your USB controllers are at 00:07.x, so I'm not surprised they weren't
> quirked.
>
> Alan, why were dev_lo and dev_hi both set to 0 for the VT82C868 in your
> implementation? Is it a typo, or...?
>
> Nick, I guess the following patch would work better for you? I've listed
> devices 00:07.x as quirkable for the VT82C686.

The VT82C686 is very different from other devices, because it is
a PCI chip, and its device number is determined by IDSEL wiring.
Google shows that several different assignments are in use:

00:01.0:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016642.html
(but that's PPC)

00:04.0: http://www.cs.helsinki.fi/linux/linux-kernel/2001-36/0083.html
00:05.0: http://lkml.org/lkml/2003/12/11/78
00:07.0: this example and lots of other links
00:14.0: http://forum.freespire.org/showthread.php?t=2998

> +static void quirk_via_bridge(struct pci_dev *dev)
> +{
> +	/* See what bridge we have and find the device ranges */
> +	switch (dev->device) {
> +	case PCI_DEVICE_ID_VIA_82C686:
> +		/* 82C686 is special */
> +		via_vlink_dev_lo = 7;
> +		via_vlink_dev_hi = 7;

So this should probably be:

		/*
		 * 82C686 attaches to PCI and can have any device number, but
		 * all its subdevices are functions of that single device.
		 */
		via_vlink_dev_lo = via_vlink_dev_hi = PCI_SLOT(dev->devfn);

Content of type "application/pgp-signature" skipped