The pci_device_id tables in linux-2.4.7-pre3/drivers/char/sonypi.c
claims that the driver wants to be loaded on all computers that have
an that have a PCI device with vendor id PCI_VENDOR_ID_INTEL and
a device ID of either PCI_DEVICE_ID_INTEL_82371AB_3 (0x7110) or
PCI_DEVICE_ID_INTEL_82801BA_10 (0x244c). My Kapok 1100m notebook
computer has an Intel 82371ab, so the sonypi module automatically
loads at boot time and hangs the computer.
sonypi_init_module needs to do some kind of test to figure out
if it is on a Sony Vaio and abort otherwise. Looking at the result of
"lspci -v" on my Sony Vaio Picturebook, I see that, while none of the
PCI devices have Sony's vendor ID, a number of them have Sony's
vendor ID as their subsystem vendor ID's. So, I have implemented the
following test to cause sonypi only to be loadable on machines that
have at least one PCI device that has a subsystem vendor ID of
PCI_VENDOR_ID_SONY.
--
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[email protected] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
Hi,
First off, it works for me on my VAIO PCG-Z600NE.
On Sun, Jul 08, 2001 at 09:30:44AM +0100, Adam J. Richter wrote:
> The pci_device_id tables in linux-2.4.7-pre3/drivers/char/sonypi.c
> claims that the driver wants to be loaded on all computers that have
> an that have a PCI device with vendor id PCI_VENDOR_ID_INTEL and
...
> "lspci -v" on my Sony Vaio Picturebook, I see that, while none of the
> PCI devices have Sony's vendor ID, a number of them have Sony's
> vendor ID as their subsystem vendor ID's. So, I have implemented the
Just a niggle however. This still isn't a very good test to finding a
Sony laptop. What'll happen on machines that have any sort of Sony
plugin device ?
How's about we test for a machine that has a host bridge with the Sony
subvendor ID, rather than any device.
WARNING!! untested code.
static int __init sonypi_init_module(void) {
struct pci_dev *dev;
if ((dev = pci_find_class(PCI_CLASS_BRIDGE_HOST << 8, NULL)) == NULL)
return -ENODEV; /* Bizzare. No host bridge */
if (dev->subsystem_vendor != PCI_VENDOR_ID_SONY)
return -ENODEV; /* Not a Sony machine */
return pci_module_init(&sonypi_driver);
}
I guess this'll still pickup Sony desktops.
Perhaps we need a survey of lspci -nv results for sony and non-sony
machines ?
--
Bob Dunlop
[email protected]
http://www.xyzzy.clara.co.uk
>From: "Robert J.Dunlop" <[email protected]>
>Hi,
>First off, it works for me on my VAIO PCG-Z600NE.
Great. Thanks for testing it!
[...]
>Just a niggle however. This still isn't a very good test to finding a
>Sony laptop. What'll happen on machines that have any sort of Sony
>plugin device ?
>How's about we test for a machine that has a host bridge with the Sony
>subvendor ID, rather than any device.
On my Sony Vaio C1VN PictureBook, the host bridge subsystem
vendor ID is Transmeta, not Sony. The device with the Sony subsystem
vendor ID are the firewire controller, sound devices, soft modem,
cardbus bridge and video. So, you could would not work on it (although
I did not actually try it).
>I guess this'll still pickup Sony desktops.
Sony desktops are also called "Vaio." I do not know whether
they have the hardware that sonypi tries to talk to.
>Perhaps we need a survey of lspci -nv results for sony and non-sony
>machines ?
Yes, although that is a task that is never complete. So, I
would recommend that we adopt a simple test that should work into the
stock kernels with the expectation that the test will probably be
refined in the future. Perhaps we could check the Cardbus bridge.
Does "lspci -v" on your Sony Vaio indicate that its cardbus bridge
have a subsystem vendor ID of Sony?
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[email protected] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
In article <[email protected]> you wrote:
> I guess this'll still pickup Sony desktops.
> Perhaps we need a survey of lspci -nv results for sony and non-sony
> machines ?
The DMI table might be bettur up to this job instead...
Hi again,
On Sun, Jul 08, 2001 at 03:26:48AM -0700, Adam J. Richter wrote:
>
> Yes, although that is a task that is never complete. So, I
> would recommend that we adopt a simple test that should work into the
> stock kernels with the expectation that the test will probably be
> refined in the future. Perhaps we could check the Cardbus bridge.
> Does "lspci -v" on your Sony Vaio indicate that its cardbus bridge
> have a subsystem vendor ID of Sony?
OK. lspic -v shows
CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80)
Subsystem: Sony Corporation: Unknown device 8082
Class 0x0607, vendor 0x1180, dev 0x0x0475, subv 0x104D, subd 0x8082
I guess that's a pretty safe signature if the other VAIO lap and
palmtops have it.
--
Bob Dunlop
[email protected]
http://www.xyzzy.clara.co.uk
On Sun, Jul 08, 2001 at 05:46:39PM +0100, you wrote:
> OK. lspic -v shows
> CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80)
> Subsystem: Sony Corporation: Unknown device 8082
> I guess that's a pretty safe signature if the other VAIO lap and
> palmtops have it.
Seems so, my Vaio shows this signature too.
00:0c.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80)
Subsystem: Sony Corporation: Unknown device 8082
Flags: bus master, medium devsel, latency 168, IRQ 9
Memory at 10000000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
I/O window 0: 00000000-00000003
I/O window 1: 00000000-00000003
16-bit legacy interface ports at 0001
HTH, alexx
--
| .-. | CCNAIA Alexander Griesser <[email protected]> | .''`. |
| /v\ | http://www.tuxx-home.at -=- ICQ:63180135 | : :' : |
| /( )\ | echo "K..?f{1,2}e[nr]b?ck" >>~/.score | `. `' |
| ^^ ^^ | Linux Version 2.4.6 - Debian Unstable | `- |
In alcove.lists.linux.kernel, you wrote:
> > Yes, although that is a task that is never complete. So, I
> > would recommend that we adopt a simple test that should work into the
> > stock kernels with the expectation that the test will probably be
> > refined in the future. Perhaps we could check the Cardbus bridge.
> > Does "lspci -v" on your Sony Vaio indicate that its cardbus bridge
> > have a subsystem vendor ID of Sony?
>
> OK. lspic -v shows
>
> CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80)
> Subsystem: Sony Corporation: Unknown device 8082
>
> Class 0x0607, vendor 0x1180, dev 0x0x0475, subv 0x104D, subd 0x8082
>
> I guess that's a pretty safe signature if the other VAIO lap and
> palmtops have it.
Except for the subsystem's device ID. My C1VE shows for the cardbus
bridge:
Class 0607: 1180:0475 (rev 80)
Subsystem: 104d:80b1
I guess we'd better test for (class,vendor,dev,subsys vendor,ANY).
A much better solution would be using the DMI tables, but the
implementation is not so immediate due to design problems (IMHO). See
my other post below.
Stelian.
--
Stelian Pop <[email protected]>
|---------------- Free Software Engineer -----------------|
| Alc?ve - http://www.alcove.com - Tel: +33 1 49 22 68 00 |
|------------- Alc?ve, liberating software ---------------|
In alcove.lists.linux.kernel, you wrote:
>
> > I guess this'll still pickup Sony desktops.
> > Perhaps we need a survey of lspci -nv results for sony and non-sony
> > machines ?
>
> The DMI table might be bettur up to this job instead...
Is seems so, my DMI tables contain some strings that we could
use to trigger up this laptop recognision (obtained after enabling
dmi_printk in the source):
DMI table at 0x000DC010.
BIOS Vendor: Phoenix Technologies LTD
BIOS Version: R0204P1
BIOS Release: 09/12/00
System Vendor: Sony Corporation .
Product Name: PCG-C1VE(FR) .
Version 01 .
Serial Number 28316054-5120966 .
Board Vendor: Sony Corporation .
Board Name: PCG-C1VE(FR) .
But it doesn't seem to me like the dmi routines (arch/i386/kernel/dmi_scan.c)
were designed to be used from outside this scope.
I could implement this in two different ways:
- add a callback in this file which will initialise
a global var we could test in the driver.
or
- export the dmi_ident tab and maybe some check routines/macros
to the rest of the kernel, giving each driver the possibility
to access this info.
What does the audience think ?
Stelian.
--
Stelian Pop <[email protected]>
|---------------- Free Software Engineer -----------------|
| Alc?ve - http://www.alcove.com - Tel: +33 1 49 22 68 00 |
|------------- Alc?ve, liberating software ---------------|
> But it doesn't seem to me like the dmi routines (arch/i386/kernel/dmi_s=
> can.c)
> were designed to be used from outside this scope.
They are designed to be __init - on the grounds that its cheaper to set
a single ickypurplebox=1 in __init code and keep the variable around than
keep the parser around
>
Based on the advice and testing of Bob Dunlop, Alexander Griesser,
[email protected], and Stelian Pop, here is a modified sonpypi.c
patch that detects Sony Vaio computers by requiring a Cardbus bridge
that has a subsystem vendor ID of Sony, rather than just any PCI device.
This should avoid erroneous(?) installation and (possible hangs?) from
this module on Sony desktop machines, although this may break if Sony
decides to make a PCI-to-Cardbus bridge card and puts its vendor ID
in the subsystem vendor ID of that device.
I've tried this code on a machine that is a Sony Vaio
notebook computer and one that is not, and it gets it right in
both cases.
I am interested in figuring out a more perfect test, but,
in all cases, this patch should be better than the current 2.4.7-pre3
tree and the earlier patches that Bob and I have posted, so it would
be fine to apply it now. (In particular, I am following the discussion
about using "DMI tables"--something I'm not familiar with--but I have
to leave for a two day trip in a few hours.)
Anyhow, I hope this patch is helpful.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
[email protected] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- linux-2.4.7-pre3/drivers/char/sonypi.c Mon Jul 9 05:32:41 2001
+++ linux/drivers/char/sonypi.c Mon Jul 9 05:30:22 2001
@@ -689,8 +689,23 @@
remove: sonypi_remove,
};
+static int __init sony_notebook(void) {
+ struct pci_dev *dev;
+
+ dev = NULL;
+ while ((dev = pci_find_class(PCI_CLASS_BRIDGE_CARDBUS, NULL)) != NULL){
+ if (dev->subsystem_vendor == PCI_VENDOR_ID_SONY)
+ return 1;
+ }
+
+ return 0;
+}
+
static int __init sonypi_init_module(void) {
- return pci_module_init(&sonypi_driver);
+ if (sony_notebook())
+ return pci_module_init(&sonypi_driver);
+ else
+ return -ENODEV;
}
static void __exit sonypi_cleanup_module(void) {
In alcove.lists.linux.kernel, you wrote:
> > But it doesn't seem to me like the dmi routines (arch/i386/kernel/dmi_s=
> > can.c)
> > were designed to be used from outside this scope.
>
> They are designed to be __init - on the grounds that its cheaper to set
> a single ickypurplebox=1 in __init code and keep the variable around than
> keep the parser around
Ok, the attached patch tests for a Sony Vaio laptop in the dmi tables
(searching for a "Sony Corporation" manufacturer string and a
"PCG-" model substring which should apply to all Vaio laptops and rule
out the Vaio desktops).
(a make mrproper is highly recommended...)
Stelian.
diff -uNr --exclude-from=dontdiff linux-2.4.6-ac2.orig/arch/i386/kernel/dmi_scan.c linux-2.4.6-ac2/arch/i386/kernel/dmi_scan.c
--- linux-2.4.6-ac2.orig/arch/i386/kernel/dmi_scan.c Mon Jul 9 10:25:52 2001
+++ linux-2.4.6-ac2/arch/i386/kernel/dmi_scan.c Mon Jul 9 14:09:58 2001
@@ -251,6 +251,25 @@
return 0;
}
+#if defined(CONFIG_SONYPI) || defined(CONFIG_SONYPI_MODULE)
+/*
+ * Check for a Sony Vaio system in order to enable the use of
+ * the sonypi driver (we don't want this driver to be used on
+ * other systems, even if they have the good PCI IDs).
+ */
+int is_sony_vaio_laptop;
+
+static __init int sony_vaio_laptop(struct dmi_blacklist *d)
+{
+ if (is_sony_vaio_laptop == 0)
+ {
+ is_sony_vaio_laptop = 1;
+ printk(KERN_INFO "%s laptop detected.\n", d->ident);
+ }
+ return 0;
+}
+#endif
+
/*
* Process the DMI blacklists
*/
@@ -302,6 +321,13 @@
MATCH(DMI_PRODUCT_NAME, "Delhi3"),
NO_MATCH, NO_MATCH,
} },
+#if defined(CONFIG_SONYPI) || defined(CONFIG_SONYPI_MODULE)
+ { sony_vaio_laptop, "Sony Vaio", { /* This is a Sony Vaio laptop */
+ MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
+ MATCH(DMI_PRODUCT_NAME, "PCG-"),
+ NO_MATCH, NO_MATCH,
+ } },
+#endif
{ NULL, }
};
diff -uNr --exclude-from=dontdiff linux-2.4.6-ac2.orig/arch/i386/kernel/i386_ksyms.c linux-2.4.6-ac2/arch/i386/kernel/i386_ksyms.c
--- linux-2.4.6-ac2.orig/arch/i386/kernel/i386_ksyms.c Mon Jul 9 10:25:52 2001
+++ linux-2.4.6-ac2/arch/i386/kernel/i386_ksyms.c Mon Jul 9 14:28:28 2001
@@ -167,4 +167,8 @@
EXPORT_SYMBOL(do_BUG);
#endif
+#if defined(CONFIG_SONYPI) || defined(CONFIG_SONYPI_MODULE)
+extern int is_sony_vaio_laptop;
+EXPORT_SYMBOL(is_sony_vaio_laptop);
+#endif
diff -uNr --exclude-from=dontdiff linux-2.4.6-ac2.orig/drivers/char/sonypi.c linux-2.4.6-ac2/drivers/char/sonypi.c
--- linux-2.4.6-ac2.orig/drivers/char/sonypi.c Mon Jul 9 10:26:01 2001
+++ linux-2.4.6-ac2/drivers/char/sonypi.c Mon Jul 9 14:10:14 2001
@@ -48,6 +48,7 @@
static int verbose; /* = 0 */
static int fnkeyinit; /* = 0 */
static int camera; /* = 0 */
+extern int is_sony_vaio_laptop; /* set in DMI table parse routines */
/* Inits the queue */
static inline void sonypi_initq(void) {
@@ -690,7 +691,10 @@
};
static int __init sonypi_init_module(void) {
- return pci_module_init(&sonypi_driver);
+ if (is_sony_vaio_laptop)
+ return pci_module_init(&sonypi_driver);
+ else
+ return -ENODEV;
}
static void __exit sonypi_cleanup_module(void) {
diff -uNr --exclude-from=dontdiff linux-2.4.6-ac2.orig/drivers/char/sonypi.h linux-2.4.6-ac2/drivers/char/sonypi.h
--- linux-2.4.6-ac2.orig/drivers/char/sonypi.h Mon Jul 9 10:26:01 2001
+++ linux-2.4.6-ac2/drivers/char/sonypi.h Mon Jul 9 15:17:55 2001
@@ -35,7 +35,7 @@
#ifdef __KERNEL__
#define SONYPI_DRIVER_MAJORVERSION 1
-#define SONYPI_DRIVER_MINORVERSION 2
+#define SONYPI_DRIVER_MINORVERSION 3
#include <linux/types.h>
#include <linux/pci.h>
--
Stelian Pop <[email protected]>
|---------------- Free Software Engineer -----------------|
| Alc?ve - http://www.alcove.com - Tel: +33 1 49 22 68 00 |
|------------- Alc?ve, liberating software ---------------|