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]
Message-Id: <1163009130.23956.57.camel@localhost.localdomain>
Date:	Wed, 08 Nov 2006 18:05:30 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Sergey Vlasov <vsu@...linux.ru>
Cc:	Sergio Monteiro Basto <sergio@...giomb.no-ip.org>, akpm@...l.org,
	Wilco Beekhuizen <wilcobeekhuizen@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: VIA IRQ quirk missing PCI ids since 2.6.16.17

Ar Mer, 2006-11-08 am 20:22 +0300, ysgrifennodd Sergey Vlasov:
> Hmm, the old comment mentions 686A/B explicitly - seems that these old
> chips also use PCI_INTERRUPT_LINE to control interrupt routing.  Is it
> correct to ignore them here?  Yes, that chips used PCI and not VLink,
> but they also had an internal PIC (and even internal IO-APIC).
> 
> Unfortunately, I no longer have such hardware available.

I have enough docs to extend this approach to those chips if neccessary.
Anyone got an old 686 board to check.

> > +	/* May not be needed for the 8237 */
> > +	{ PCI_VDEVICE(VIA, PCI_DEVICE_ID_VIA_8237), 15 },
> > +	{ PCI_VDEVICE(VIA, PCI_DEVICE_ID_VIA_8237A), 15 },
> 
> 8237 definitely uses PCI_INTERRUPT_LINE to control interrupt routing in
> PIC mode - tested with the audio part by writing bogus values with
> setpci and checking whether interrupts are delivered.

Ok

> If there is no VIA ISA bridge in the system, this won't cache anything.

I no, thats noted in the comments when I posted the diff. If it works
I'll cache ->driver_data instead.

> > -int pci_dev_present(const struct pci_device_id *ids)
> > +struct pci_device_id *pci_find_present(const struct pci_device_id *ids)
> 
> New API without proper refcounting?  Ewww.

pci_device_id objects are not refcounted and don't vanish underneath us.
Devices may but we aren't dealing in devices. The function operates
under the list lock internally so should be safe.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ