[PATCH] 2.5.31 driverfs: patch for your consideration

[PATCH] 2.5.31 driverfs: patch for your consideration

[Adam Belay]

Here's the patch as we discussed.

diff -ur --new-file a/drivers/base/interface.c b/drivers/base/interface.c
--- a/drivers/base/interface.c    Wed Aug 14 17:09:28 2002
+++ b/drivers/base/interface.c    Fri Aug 16 22:03:18 2002
@@ -88,8 +88,20 @@
 static DEVICE_ATTR(power,"power",S_IWUSR | S_IRUGO,
            device_read_power,device_write_power);
 
+
+static ssize_t device_read_driver(struct device * dev, char * buf, 
size_t count, loff_t off)
+{
+    if (dev->driver)
+        return off ? 0 : sprintf(buf,"%s\n",dev->driver->name);
+    else
+        return 0;
+}
+
+static DEVICE_ATTR(driver,"driver",S_IRUGO,device_read_driver,NULL);
+
 struct device_attribute * device_default_files[] = {
     &dev_attr_name,
     &dev_attr_power,
+    &dev_attr_driver,
     NULL,
 };





Also if You're interested here's the write support for "driver".

diff -ur --new-file a/drivers/base/base.h b/drivers/base/base.h
--- a/drivers/base/base.h    Fri Aug 16 12:20:18 2002
+++ b/drivers/base/base.h    Fri Aug 16 22:17:26 2002
@@ -26,3 +26,5 @@
 
 extern int driver_attach(struct device_driver * drv);
 extern void driver_detach(struct device_driver * drv);
+extern int do_driver_detach(struct device * dev, struct device_driver * 
drv);
+extern int do_driver_attach(struct device * dev, void * data);
diff -ur --new-file a/drivers/base/core.c b/drivers/base/core.c
--- a/drivers/base/core.c    Wed Aug 14 17:09:28 2002
+++ b/drivers/base/core.c    Fri Aug 16 22:16:30 2002
@@ -98,7 +98,7 @@
 
 static void device_detach(struct device * dev)
 {
-    struct device_driver * drv;
+    struct device_driver * drv;
 
     if (dev->driver) {
         lock_device(dev);
@@ -117,7 +117,7 @@
     }
 }
 
-static int do_driver_attach(struct device * dev, void * data)
+int do_driver_attach(struct device * dev, void * data)
 {
     struct device_driver * drv = (struct device_driver *)data;
     int error = 0;
@@ -134,7 +134,7 @@
     return bus_for_each_dev(drv->bus,drv,do_driver_attach);
 }
 
-static int do_driver_detach(struct device * dev, struct device_driver * 
drv)
+int do_driver_detach(struct device * dev, struct device_driver * drv)
 {
     lock_device(dev);
     if (dev->driver == drv) {
diff -ur --new-file a/drivers/base/interface.c b/drivers/base/interface.c
--- a/drivers/base/interface.c    Fri Aug 16 22:06:41 2002
+++ b/drivers/base/interface.c    Fri Aug 16 22:15:29 2002
@@ -8,6 +8,7 @@
 #include <linux/device.h>
 #include <linux/err.h>
 #include <linux/stat.h>
+#include "base.h"
 
 static ssize_t device_read_name(struct device * dev, char * buf, size_t 
count, loff_t off)
 {
@@ -97,7 +98,44 @@
         return 0;
 }
 
-static DEVICE_ATTR(driver,"driver",S_IRUGO,device_read_driver,NULL);
+struct device_driver * find_driver_by_name(struct bus_type * bus, char 
* name)
+{
+    struct list_head * pos;
+    struct device_driver * drv;
+    list_for_each (pos, &bus->drivers)
+    {
+        drv = list_entry(pos, struct device_driver, bus_list);
+        if (!strncmp(drv->name,name,strlen(name) - 1))
+            return drv;
+
+    }
+    return NULL;
+
+}
+
+static ssize_t device_write_driver(struct device * dev, char * buf, 
size_t count, loff_t off)
+{
+    struct device_driver * drv = NULL;
+    int error = 0;
+    if (off)
+        return 0;
+    if (!dev->bus)
+        return count;
+    if (!dev->driver)
+    {
+        drv = find_driver_by_name(dev->bus, buf);
+        if (drv)
+            error = do_driver_attach(dev,drv);
+
+    } else if (!strnicmp(buf,"remove",6))
+    {
+        error = do_driver_detach(dev, dev->driver);
+    }
+    return error < 0 ? error : count;
+}
+
+static DEVICE_ATTR(driver,"driver",S_IWUSR | S_IRUGO,
+           device_read_driver,device_write_driver);
 
 struct device_attribute * device_default_files[] = {
     &dev_attr_name,



I look forward to hearing from you.

Thanks,
Adam

PS:   Would you be interested in a patch that would port the pnpbios 
driver to the driver model?

Re: [PATCH] 2.5.31 driverfs: patch for your consideration

[Greg KH]

On Fri, Aug 16, 2002 at 10:36:00PM +0000, Adam Belay wrote:
> Here's the patch as we discussed.

Um, your email client mangled the patch, dropping tabs and wrapped
lines.

> +static ssize_t device_read_driver(struct device * dev, char * buf, 
> size_t count, loff_t off)
> +{
> +    if (dev->driver)
> +        return off ? 0 : sprintf(buf,"%s\n",dev->driver->name);
> +    else
> +        return 0;
> +}

Isn't this info already in the "name" file of a driver?


> +struct device_driver * find_driver_by_name(struct bus_type * bus, char 
> * name)
> +{
> +    struct list_head * pos;
> +    struct device_driver * drv;
> +    list_for_each (pos, &bus->drivers)
> +    {
> +        drv = list_entry(pos, struct device_driver, bus_list);
> +        if (!strncmp(drv->name,name,strlen(name) - 1))
> +            return drv;
> +
> +    }
> +    return NULL;
> +
> +}

Not that I agree with this patch at all, but you might want to go read
Documentation/CodingStyle to fix up your brace placement properly.

thanks,

greg k-h

Re: [PATCH] 2.5.31 driverfs: patch for your consideration

[David D. Hagood]

Adam Belay wrote:

> +static ssize_t device_read_driver(struct device * dev, char * buf, 
> size_t count, loff_t off)
> +{
> +    if (dev->driver)
> +        return off ? 0 : sprintf(buf,"%s\n",dev->driver->name);

You aren't checking that the name will fit in the supplied buffer - what 
is there isn't enough space? Shouldn't you either use snprintf, a 
strncpy, or a maximum field width in the sprintf?

Re: [PATCH] 2.5.31 driverfs: patch for your consideration

[Adam Belay]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]



greg@kroah.com wrote:

 >
 >Um, your email client mangled the patch, dropping tabs and wrapped
 >lines.
 >
Thanks for pointing this out.  I'll send it as an attachment this time.
  My current client has been causing me a lot of trouble, is there one
you would suggest I use?

 >
 >Isn't this info already in the "name" file of a driver?
 >

I'm probably just confused but I'm not sure what you mean.  This patch 
does the following, as shown previously:

example:
#cd /driverfs/root/pci0/00:00.0
#cat driver
agpgart

 >
 >Not that I agree with this patch at all, but you might want to go read
 >Documentation/CodingStyle to fix up your brace placement properly.
 >

Ok I'll read it.

 >

Thanks,
Adam


[-- Attachment #2: driver.patch --]
[-- Type: text/plain, Size: 731 bytes --]

diff -ur --new-file a/drivers/base/interface.c b/drivers/base/interface.c
--- a/drivers/base/interface.c  Wed Aug 14 17:09:28 2002
+++ b/drivers/base/interface.c  Fri Aug 16 22:03:18 2002
@@ -88,8 +88,20 @@
 static DEVICE_ATTR(power,"power",S_IWUSR | S_IRUGO,
           device_read_power,device_write_power);
 
+
+static ssize_t device_read_driver(struct device * dev, char * buf, size_t count, loff_t off)
+{
+   if (dev->driver)
+       return off ? 0 : sprintf(buf,"%s\n",dev->driver->name);
+   else
+       return 0;
+}
+
+static DEVICE_ATTR(driver,"driver",S_IRUGO,device_read_driver,NULL);
+
 struct device_attribute * device_default_files[] = {
    &dev_attr_name,
    &dev_attr_power,
+   &dev_attr_driver,
    NULL,
 };

[-- Attachment #3: driver2.patch --]
[-- Type: text/plain, Size: 2899 bytes --]

diff -ur --new-file a/drivers/base/base.h b/drivers/base/base.h
--- a/drivers/base/base.h   Fri Aug 16 12:20:18 2002
+++ b/drivers/base/base.h   Fri Aug 16 22:17:26 2002
@@ -26,3 +26,5 @@
 
 extern int driver_attach(struct device_driver * drv);
 extern void driver_detach(struct device_driver * drv);
+extern int do_driver_detach(struct device * dev, struct device_driver * drv);
+extern int do_driver_attach(struct device * dev, void * data);
diff -ur --new-file a/drivers/base/core.c b/drivers/base/core.c
--- a/drivers/base/core.c   Wed Aug 14 17:09:28 2002
+++ b/drivers/base/core.c   Fri Aug 16 22:16:30 2002
@@ -98,7 +98,7 @@
 
 static void device_detach(struct device * dev)
 {
-   struct device_driver * drv; 
+   struct device_driver * drv;
 
    if (dev->driver) {
        lock_device(dev);
@@ -117,7 +117,7 @@
    }
 }
 
-static int do_driver_attach(struct device * dev, void * data)
+int do_driver_attach(struct device * dev, void * data)
 {
    struct device_driver * drv = (struct device_driver *)data;
    int error = 0;
@@ -134,7 +134,7 @@
    return bus_for_each_dev(drv->bus,drv,do_driver_attach);
 }
 
-static int do_driver_detach(struct device * dev, struct device_driver * drv)
+int do_driver_detach(struct device * dev, struct device_driver * drv)
 {
    lock_device(dev);
    if (dev->driver == drv) {
diff -ur --new-file a/drivers/base/interface.c b/drivers/base/interface.c
--- a/drivers/base/interface.c  Fri Aug 16 22:06:41 2002
+++ b/drivers/base/interface.c  Fri Aug 16 22:15:29 2002
@@ -8,6 +8,7 @@
 #include <linux/device.h>
 #include <linux/err.h>
 #include <linux/stat.h>
+#include "base.h"
 
 static ssize_t device_read_name(struct device * dev, char * buf, size_t count, loff_t off)
 {
@@ -97,7 +98,44 @@
        return 0;
 }
 
-static DEVICE_ATTR(driver,"driver",S_IRUGO,device_read_driver,NULL);
+struct device_driver * find_driver_by_name(struct bus_type * bus, char * name)
+{
+   struct list_head * pos;
+   struct device_driver * drv;
+   list_for_each (pos, &bus->drivers)
+   {
+       drv = list_entry(pos, struct device_driver, bus_list);
+       if (!strncmp(drv->name,name,strlen(name) - 1))
+           return drv;
+
+   }
+   return NULL;
+
+}
+
+static ssize_t device_write_driver(struct device * dev, char * buf, size_t count, loff_t off)
+{
+   struct device_driver * drv = NULL;
+   int error = 0;
+   if (off)
+       return 0;
+   if (!dev->bus)
+       return count;
+   if (!dev->driver)
+   {
+       drv = find_driver_by_name(dev->bus, buf);
+       if (drv)
+           error = do_driver_attach(dev,drv);
+
+   } else if (!strnicmp(buf,"remove",6))
+   {
+       error = do_driver_detach(dev, dev->driver);
+   }
+   return error < 0 ? error : count;
+}
+
+static DEVICE_ATTR(driver,"driver",S_IWUSR | S_IRUGO,
+          device_read_driver,device_write_driver);
 
 struct device_attribute * device_default_files[] = {
    &dev_attr_name,

Re: [PATCH] 2.5.31 driverfs: patch for your consideration

[Greg KH]

On Sat, Aug 17, 2002 at 02:10:34PM +0000, Adam Belay wrote:
> 
> 
> greg@kroah.com wrote:
> 
> >
> >Um, your email client mangled the patch, dropping tabs and wrapped
> >lines.
> >
> Thanks for pointing this out.  I'll send it as an attachment this time.
>  My current client has been causing me a lot of trouble, is there one
> you would suggest I use?

I like mutt, but that's just my opinion :)

Hm, in looking at your attachments, they will not apply either.  All the
tabs are gone, something's wrong with your originals.  Did you cut and
paste to generate them?

> >
> >Isn't this info already in the "name" file of a driver?
> >
> 
> I'm probably just confused but I'm not sure what you mean.  This patch 
> does the following, as shown previously:
> 
> example:
> #cd /driverfs/root/pci0/00:00.0
> #cat driver
> agpgart

Ah, got it, nevermind :)

thanks,

greg k-h

Re: [PATCH] 2.5.31 driverfs: patch for your consideration

[Alan Cox]

On Fri, 2002-08-16 at 23:36, Adam Belay wrote:
> +static ssize_t device_read_driver(struct device * dev, char * buf, 
> size_t count, loff_t off)
> +{
> +    if (dev->driver)
> +        return off ? 0 : sprintf(buf,"%s\n",dev->driver->name);
> +    else
> +        return 0;

Unless you can prove without doubt between now and the end of time the
size is sufficient use snprintf 

Re: [PATCH] 2.5.31 driverfs: patch for your consideration

[Adam Belay]

[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]



greg@kroah.com wrote:

>On Sat, Aug 17, 2002 at 02:10:34PM +0000, Adam Belay wrote:
>
>>
>>greg@kroah.com wrote:
>>
>>>Um, your email client mangled the patch, dropping tabs and wrapped
>>>lines.
>>>
>>Thanks for pointing this out.  I'll send it as an attachment this time.
>> My current client has been causing me a lot of trouble, is there one
>>you would suggest I use?
>>
>
>I like mutt, but that's just my opinion :)
>
>Hm, in looking at your attachments, they will not apply either.  All the
>tabs are gone, something's wrong with your originals.  Did you cut and
>paste to generate them?
>
I downloaded my patches through the mailing list and applied them:

bash-2.05a$ cat ./driver.patch | patch -p1 -l -d linux
patching file drivers/base/interface.c
bash-2.05a$ cat ./driver2.patch | patch -p1 -l -d linux
patching file drivers/base/base.h
patching file drivers/base/core.c
patching file drivers/base/interface.c

It applies cleanly but . . .

You're right the tabs are gone although when I applied my originals they 
weren't.  I hate netscape navigator.  I gzipped them so netscape can't 
mess them up.  In the meantime I'm going to download mutt.  Thanks for 
your help.  Let me know if the patch works this time.  Also after 
looking at the interface code I realized that not just my code used 
sprintf.  Do you think they should all use snprintf instead or is the 
probability of a driver attribute exceeding the one page buffer size so 
low that it doesn't matter?

Also I was wondering if you think resource management variables (irq, 
io, dma, etc) should live in the device structure like power management 
variables do?  Global resource management seams interesting to me, 
although there already is a proc interface that does list resources, I'm 
wondering if the driver model is a good place to put such an interface?

Thanks,
-Adam



[-- Attachment #2: driver.tar.gz --]
[-- Type: application/octet-stream, Size: 1202 bytes --]

Re: [PATCH] 2.5.31 driverfs: patch for your consideration

[Greg KH]

On Sat, Aug 17, 2002 at 10:32:30PM +0000, Adam Belay wrote:
> Also after looking at the interface code I realized that not just my
> code used sprintf.  Do you think they should all use snprintf instead
> or is the probability of a driver attribute exceeding the one page
> buffer size so low that it doesn't matter?

snprintf is always a good idea to be using.

> Also I was wondering if you think resource management variables (irq, 
> io, dma, etc) should live in the device structure like power management 
> variables do?

Lots of different devices do not have irq, io, and dma assigned to them
(like every USB device).  These values should be on a per-bus type (i.e.
most pci devices _do_ have those types of values.

> Global resource management seams interesting to me, although there
> already is a proc interface that does list resources, I'm wondering if
> the driver model is a good place to put such an interface?

Yes it is a good place to put them, as almost every /proc file that does
not deal with processes will eventually be moving to this fs.

thanks,

greg k-h

Re: [PATCH] 2.5.31 driverfs: patch for your consideration

[Greg KH]

On Sat, Aug 17, 2002 at 10:32:30PM +0000, Adam Belay wrote:
>  Let me know if the patch works this time.

Yes, your patch does work this time, but the coding style is still wrong :)

thanks,

greg k-h

Re: [PATCH] 2.5.31 driverfs: patch for your consideration

[Adam Belay]

mochel@osdl.org wrote:

>
>patch -l does not imply cleanly. That will ignore the whitespace munging 
>that your MUA is doing. 
>
You're right it's incorrect to say cleanly

>>also I was wondering if you think resource management variables (irq,
>>io, dma, etc) should live in the device structure like power management
>>variables do?  Global resource management seams interesting to me,
>>although there already is a proc interface that does list resources, I'm
>>wondering if the driver model is a good place to put such an interface?
>>
>
>Yes. We talked about doing that from the very beginning, and were going to 
>see how things worked out. There was some discussion about this at OLS, 
>too. But, I'm not sure it's ready for it yet.
>
That's great, I think there's a big advantage doing this because if this 
data lies in the driver model code then it's very easy to standardize 
interfaces for hardware and power management

>
>
>What would be nice would be some way to cleanly represent conditional 
>attributes of devices, like resource and power management. I think I 
>almost have something with the device interface stuff, but I fear it's a 
>fine line to cross over into Abstraction Hell... 
>
Could you please send me a patch, if there is one, concerning your work 
with conditional attributes, I'd love to take a look.  If we could work 
something out like this it would solve all kinds of problems.  I'll look 
into it.  Remember that devfs patch I had a while ago.  Instead of using 
devfs handles I could use kdev_t and export the major and minor through 
a conditional attribute.  If so should a list of major and minor pairs 
be in one file?


Also when you say conditional attributes do you mean conditional in the 
device structure as well.  In other words do you mean a list or hash of 
attributes in the device structure?

Thanks,
Adam

Re: [PATCH] 2.5.31 driverfs: patch for your consideration

[Adam Belay]

mochel@osdl.org wrote:

>>Also if You're interested here's the write support for "driver".
>>
>
>Suppose we did support this. If you write the name of a driver to a file, 
>we search the bus's list of drivers for a match. We then let the bus 
>compare the hardware IDs and call probe if it matches. 
>
That's exactly how my code works.

>
>
>One big problem is that the IDs in the driver are marked __devinitdata, so
>they're thrown away after init (if hotplugging is not enabled). So, we 
>would have to change every driver.
>
Found that out when I tested binding the agpgart driver.

> 
>
>Besides, it just doesn't make sense. If $user wants to use a different 
>or third party driver, let them rmmod and insmod. 
>
Ok, I guess that makes sense.  My interface was primarily for special 
cases anyway.  What does need to be done is a user level program that 
finds and loads the proper modules automatically.  Maybe we could use 
the existing hotplug scripts or we could even start from scratch.  Maybe 
we should make a file in the source tree where driver developers can 
list their supported hardware IDs but more importantly documentation on 
the attributes registered into driverfs.

>
>
>>PS:  Would you be interested in a patch that would port the pnpbios
>>driver to the driver model?
>>
>
>Yes. 
>
great!

Thanks,
Adam

Re: [PATCH] 2.5.31 driverfs: patch for your consideration

[Patrick Mochel]

> I downloaded my patches through the mailing list and applied them:
> 
> bash-2.05a$ cat ./driver.patch | patch -p1 -l -d linux
> patching file drivers/base/interface.c
> bash-2.05a$ cat ./driver2.patch | patch -p1 -l -d linux
> patching file drivers/base/base.h
> patching file drivers/base/core.c
> patching file drivers/base/interface.c
> 
> It applies cleanly but . . .

patch -l does not imply cleanly. That will ignore the whitespace munging 
that your MUA is doing. 

> You're right the tabs are gone although when I applied my originals they 
> weren't.  I hate netscape navigator.  I gzipped them so netscape can't 
> mess them up.  In the meantime I'm going to download mutt.  Thanks for 
> your help.  Let me know if the patch works this time.  Also after 
> looking at the interface code I realized that not just my code used 
> sprintf.  Do you think they should all use snprintf instead or is the 
> probability of a driver attribute exceeding the one page buffer size so 
> low that it doesn't matter?

They should use snprintf. Thanks for pointing that out. 

> Also I was wondering if you think resource management variables (irq,
> io, dma, etc) should live in the device structure like power management
> variables do?  Global resource management seams interesting to me,
> although there already is a proc interface that does list resources, I'm
> wondering if the driver model is a good place to put such an interface?

Yes. We talked about doing that from the very beginning, and were going to 
see how things worked out. There was some dicussion about this at OLS, 
too. But, I'm not sure it's ready for it yet.

What would be nice would be some way to cleanly represent conditional 
attributes of devices, like resource and power management. I think I 
almost have something with the device interface stuff, but I fear it's a 
fine line to cross over into Abstraction Hell... 

</tangent>

	-pat

Re: [PATCH] 2.5.31 driverfs: patch for your consideration

[Patrick Mochel]

> Also if You're interested here's the write support for "driver".

This just doesn't make sense. When a device is inserted or a driver is
loaded, the bus tries to attach devices to a driver by comparing the
hardware ID of a device to the list of supported IDs of a driver. This is
handled at the bus level because the format of the ID and the semantics
for matching them are bus-specific.

Regardless, it happens automatically. It just doesn't make sense to let 
people try and bind a device to some random driver. 

Suppose we did support this. If you write the name of a driver to a file, 
we search the bus's list of drivers for a match. We then let the bus 
compare the hardware IDs and call probe if it matches. 

One big problem is that the IDs in the driver are marked __devinitdata, so
they're thrown away after init (if hotplugging is not enabled). So, we 
would have to change every driver. 

Besides, it just doesn't make sense. If $user wants to use a different 
or third party driver, let them rmmod and insmod. 

> PS:  Would you be interested in a patch that would port the pnpbios
> driver to the driver model?

Yes. 

	-pat

Re: [PATCH] 2.5.31 driverfs: patch for your consideration

[Greg KH]

On Mon, Aug 19, 2002 at 03:50:57PM +0000, Adam Belay wrote:
> What does need to be done is a user level program that finds and loads
> the proper modules automatically.  Maybe we could use the existing
> hotplug scripts or we could even start from scratch.  

Um, the current hotplug scripts, and my diethotplug program already do
this.  Why write another user program to do this?  What problem are you
trying to solve?

> Maybe we should make a file in the source tree where driver developers
> can list their supported hardware IDs but more importantly
> documentation on the attributes registered into driverfs.

The support hardware ids are already in the source code, and can be
easily extracted, that is what depmod(8) does to build the modules.*map
files.  See the linux-hotplug documentation at
http://linux-hotplug.sf.net/ and this article:
	http://www.linuxjournal.com/article.php?sid=5604
on how all of this works.  I need to move that article into the
Documentation/DocBook directory someday soon...

driverfs documentation could be retrieved with the DEVICE_ATTR macro, if
we _really_ throught this would be useful.

thanks,

greg k-h

Re: [PATCH] 2.5.31 driverfs: patch for your consideration

[Adam Belay]

greg@kroah.com wrote:

>
>Um, the current hotplug scripts, and my diethotplug program already do
>this.  Why write another user program to do this?  What problem are you
>trying to solve?
>
Nevermind, I wasn't very aware of them.  Looking at them now they look 
like they'd be great for this.  By the way, is diethotplug a space 
efficient binary version of the hotplug scripts or is there more to it 
then that?

Thanks,
Adam

Re: [PATCH] 2.5.31 driverfs: patch for your consideration

[Greg KH]

On Mon, Aug 19, 2002 at 09:54:35PM +0000, Adam Belay wrote:
> By the way, is diethotplug a space efficient binary version of the
> hotplug scripts or is there more to it then that?

Yes it is a space efficient version (the resulting binary is usually
300% smaller than the original modules.*map files being used.)  It
achieves these space savings at the expense of flexibility, the binary
is always tied to a specific kernel version.

Embedded and rescue disk distros are using the program, as a replacement
for the hotplug scripts, but the primary purpose is for the program to
live in initramfs and be used as part of the normal kernel boot process.

thanks,

greg k-h

Re: [PATCH] 2.5.31 driverfs: patch for your consideration

[jw schultz]

On Mon, Aug 19, 2002 at 08:32:55PM -0700, Greg KH wrote:
> On Mon, Aug 19, 2002 at 09:54:35PM +0000, Adam Belay wrote:
> > By the way, is diethotplug a space efficient binary version of the
> > hotplug scripts or is there more to it then that?
> 
> Yes it is a space efficient version (the resulting binary is usually
> 300% smaller than the original modules.*map files being used.)  It
> achieves these space savings at the expense of flexibility, the binary
> is always tied to a specific kernel version.

My apologies if you meant 30%

<rant>

Arrgh!  Please explain the math.  How can something be more
than 100% smaller than something else.

I know it is OT but this marketing math really bugs me.
i've yet to see anyone explain how y = x - (3x) where x < 0
and y <= 0 can yield a positive number without first proving
-1 == 1.

</rant>


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: [PATCH] 2.5.31 driverfs: patch for your consideration

[Greg KH]

On Mon, Aug 19, 2002 at 11:51:59PM -0700, jw schultz wrote:
> On Mon, Aug 19, 2002 at 08:32:55PM -0700, Greg KH wrote:
> > On Mon, Aug 19, 2002 at 09:54:35PM +0000, Adam Belay wrote:
> > > By the way, is diethotplug a space efficient binary version of the
> > > hotplug scripts or is there more to it then that?
> > 
> > Yes it is a space efficient version (the resulting binary is usually
> > 300% smaller than the original modules.*map files being used.)  It
> > achieves these space savings at the expense of flexibility, the binary
> > is always tied to a specific kernel version.
> 
> My apologies if you meant 30%

Very sorry, I ment that the original modules.*map files are 300% larger
than the diethotplug binary.

Hm, for the options I use in 2.5.31 I get these results:
  modules.pcimap	  6273 bytes
  modules.usbmap	 98513 bytes
  modules.ieee1394map	    73 bytes
  ----------------------------------
  total			104859 bytes

  diethotplug binary	 16332 bytes

Looks like the modules.*map files are closer to 650% larger :)

thanks,

greg k-h

[PATCH] 2.5.31 port PnP BIOS to the driver model

[Adam Belay]

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

The attached patch ports the PnP BIOS driver to the driver model as well 
as other improvements in driver and device management.  It has been tested.

Thanks,
-Adam

The following are potential changes for future pnpbios patches listed in 
order of priority.  Let me know if you support them.

1.) Add pnpbios specific interfaces to the driver model, this includes 
resource management and escd.
2.) add pnpbios dev id list support, similiar to the devlist found in pci
3.) remove dependancy on struct pci_dev and create a pnpbios specific 
dev structure
4.) split the pnpbios files into smaller more manageable files as well 
as other cleanups
5.) port some drivers to use the pnpbios driver if available.  Should 
this include the pci driver?

[-- Attachment #2: pnpbios1.patch.gz --]
[-- Type: application/octet-stream, Size: 2556 bytes --]

[PATCH] 2.5.32 port PnP BIOS to the driver model RESEND #1

[Adam Belay]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

As we discussed earlier, I converted the PnP BIOS driver to the driver 
model  Please advice on any changes you would like.  I look forward to 
hearing from you.

Thanks,
-Adam





The following are potential changes for future pnpbios patches listed in
order of priority.  Let me know if you support them.

1.) Add pnpbios specific interfaces to the driver model, this includes
resource management and escd.
2.) add pnpbios dev id list support, similiar to the devlist found in pci
3.) remove dependancy on struct pci_dev and create a pnpbios specific
dev structure
4.) split the pnpbios files into smaller more manageable files as well
as other cleanups
5.) port some drivers to use the pnpbios driver if available.  Should
this include the pci driver?


[-- Attachment #2: pnpbios1.patch.gz --]
[-- Type: application/octet-stream, Size: 2529 bytes --]

Re: [PATCH] 2.5.32 port PnP BIOS to the driver model RESEND #1

[Greg KH]

On Tue, Aug 27, 2002 at 09:40:54PM +0000, Adam Belay wrote:
> As we discussed earlier, I converted the PnP BIOS driver to the driver 
> model  Please advice on any changes you would like.  I look forward to 
> hearing from you.

Hi,

I don't have a box with a PnP BIOS (well, I don't think I do...), so
could you send the relevant portions of the driverfs tree, showing the
new devices that you add for this bus?

Also a few minor comments on the patch:
	- pnpbios_bus_type should probably be made static, along with
	  alloc_pnpbios_root().
	- You don't check for out of memory in alloc_pnpbios_root() when
	  you call kmalloc().
	- why are you modifying the set_limit() parameters at the top of
	  your patch?  That doesn't seem relevant to the driverfs
	  changes.
	- in pnpbios_bus_match(), don't you have to check the value of
	  the call to match_device() to make sure you have a match?
	  That would keep pnpbios_device_probe() from being called for
	  every device like it looks your patch causes.
	- the pnpbios_device_probe() call should return a negative error
	  number if the device does not match, or some error happens.
	  Returning 1 does not mean success.  You also need to save off
	  the device specific info somehow in your structure, so that
	  the pnpbios_device_remove() can remove it.  Or am I just
	  missing something here?

And is there some way you can inline the patch?  It wasn't that big...

thanks,

greg k-h

Re: [PATCH] 2.5.32 port PnP BIOS to the driver model RESEND #1

[Adam Belay]

[-- Attachment #1: Type: text/plain, Size: 2783 bytes --]



greg@kroah.com wrote:

>
>Hi,
>
>I don't have a box with a PnP BIOS (well, I don't think I do...), so
>could you send the relevant portions of the driverfs tree, showing the
>new devices that you add for this bus?
>
Just out of curiosity what architecture are you using, is it one that 
doesn't support PnP BIOS?

Here they are:
/driverfs/device/pnp
/driverfs/device/pnp/01
/driverfs/device/pnp/02
/driverfs/device/pnp/03
etc.
/driverfs/bus/pnp
/driverfs/bus/pnp/devices
etc.
/driverfs/bus/pnp/drivers
etc.

>
>
>Also a few minor comments on the patch:
>    - pnpbios_bus_type should probably be made static, along with
>      alloc_pnpbios_root().
>
alloc_pnpbios_root is now static.  I'm going to leave bus_type as it is 
because I want it open to other files at least for now.

>
>    - You don't check for out of memory in alloc_pnpbios_root() when
>      you call kmalloc().
>
Thanks for pointing it out, fixed it.

>
>    - why are you modifying the set_limit() parameters at the top of
>      your patch?  That doesn't seem relevant to the driverfs
>      changes.
>
The pnpbios driver will not compile without these changes, it was broken 
a few versions back.  I also made some improvements to insert_device.

>
>    - in pnpbios_bus_match(), don't you have to check the value of
>      the call to match_device() to make sure you have a match?
>      That would keep pnpbios_device_probe() from being called for
>      every device like it looks your patch causes.
>
I did some serious restructuring here and in pnpbios_device_probe.  Also 
I made it a bit more like the one used by pci.  Hopefully it's all right 
now.

>
>    - the pnpbios_device_probe() call should return a negative error
>      number if the device does not match, or some error happens.
>      Returning 1 does not mean success.  You also need to save off
>      the device specific info somehow in your structure, so that
>      the pnpbios_device_remove() can remove it.  Or am I just
>      missing something here?
>
pnpbios_device_probe now returns a negative number on failure.  I'm 
creating a more flexible pnpbios specific device data structure that can 
be used instead of pci_dev in my next patch.  I should be able to clean 
some of this up once I do that.  I'll take care of the device specific 
info then.

>
>
>And is there some way you can inline the patch?  It wasn't that big...
>
Yep, I'm getting a new isp and email address soon, then I'll be able to 
use Mutt instead of Mozzila.  It turns out netscape mail doesn't really 
use imap like it appeared to, so it's incompatible.  For now this is the 
only safe way I can send patches.

>
>
>thanks,
>
>greg k-h
>
Thank you for reviewing my patch.  I appreciate it.  If there are any 
other issues please let me know.

thanks,
Adam

[-- Attachment #2: pnpbios1-rev1.patch.gz --]
[-- Type: application/octet-stream, Size: 2708 bytes --]

Re: [PATCH] 2.5.32 port PnP BIOS to the driver model RESEND #1

[Greg KH]

On Thu, Aug 29, 2002 at 08:36:01PM +0000, Adam Belay wrote:
> 
> 
> greg@kroah.com wrote:
> 
> >
> >Hi,
> >
> >I don't have a box with a PnP BIOS (well, I don't think I do...), so
> >could you send the relevant portions of the driverfs tree, showing the
> >new devices that you add for this bus?
> >
> Just out of curiosity what architecture are you using, is it one that 
> doesn't support PnP BIOS?

i386, with PnP BIOS support turned off :)

I haven't tried enabling this before, what kind of devices does it
enable?

> Here they are:
> /driverfs/device/pnp
> /driverfs/device/pnp/01
> /driverfs/device/pnp/02
> /driverfs/device/pnp/03
> etc.
> /driverfs/bus/pnp
> /driverfs/bus/pnp/devices
> etc.
> /driverfs/bus/pnp/drivers
> etc.

But what are these devices?  Can you run 'tree' on this so as to
visualize the structure better?

> >Also a few minor comments on the patch:
> >   - pnpbios_bus_type should probably be made static, along with
> >     alloc_pnpbios_root().
> >
> alloc_pnpbios_root is now static.  I'm going to leave bus_type as it is 
> because I want it open to other files at least for now.

Why?  I don't think there's a need for any other code to need to point
to it.  If in the future it's needed, you can always export it :)

> >   - in pnpbios_bus_match(), don't you have to check the value of
> >     the call to match_device() to make sure you have a match?
> >     That would keep pnpbios_device_probe() from being called for
> >     every device like it looks your patch causes.
> >
> I did some serious restructuring here and in pnpbios_device_probe.  Also 
> I made it a bit more like the one used by pci.  Hopefully it's all right 
> now.

Wrong placement of your {} in the while statement :)
You also might want to not hard code the "7" in the memcmp, but use the
size of the smaller field there, incase things change in the future.

> >   - the pnpbios_device_probe() call should return a negative error
> >     number if the device does not match, or some error happens.
> >     Returning 1 does not mean success.  You also need to save off
> >     the device specific info somehow in your structure, so that
> >     the pnpbios_device_remove() can remove it.  Or am I just
> >     missing something here?
> >
> pnpbios_device_probe now returns a negative number on failure.  I'm 
> creating a more flexible pnpbios specific device data structure that can 
> be used instead of pci_dev in my next patch.  I should be able to clean 
> some of this up once I do that.  I'll take care of the device specific 
> info then.

But it still looks like you aren't saving off the needed information in
the dev.driver_data structure.  Or am I missing something?

thanks,

greg k-h

Re: [PATCH] 2.5.32 port PnP BIOS to the driver model RESEND #1

[Adam Belay]

greg@kroah.com wrote

>
>i386, with PnP BIOS support turned off :)
>
>I haven't tried enabling this before, what kind of devices does it
>enable?
>
It mainly controls system devices that aren't shown by the currently 
supported buses.  These include devices ranging from the pc speaker to 
the monitor.  I encourage you to try it out.  It allows the user to 
change the resources used by these devices and provides information for 
drivers.  It also can be used to enable devices that were disabled by 
the BIOS.  Here's a list of supported devices.  I hope to incorporate 
this list into the pnpbios driver in the future.

ID range    Category
--------        -------------
PNP0xxx     System devices
PNP8xxx            Network adapters
PNPAxxx     SCSI, proprietary CD adapters
PNPBxxx     Sound, video capture, multimedia
PNPCxxx - Dxxx    Modems

The following device ID is provided only for compatibility
with earlier device ID lists:

Device ID    Description
--------        -------------
PNP0802            Microsoft Sound System-compatible device
                (obsolete; use PNPB0xx instead)

---------------------------------------------------------------------------
Device ID       Description
--------        -------------
***** System Devices - PNP0xxx **************************
--Interrupt Controllers--
PNP0000         AT Interrupt Controller
PNP0001         EISA Interrupt Controller
PNP0002         MCA Interrupt Controller
PNP0003         APIC
PNP0004         Cyrix SLiC MP interrupt controller

--Timers--
PNP0100         AT Timer
PNP0101         EISA Timer
PNP0102         MCA Timer

--DMA--
PNP0200         AT DMA Controller
PNP0201         EISA DMA Controller
PNP0202         MCA DMA Controller

--Keyboards--
PNP0300         IBM PC/XT keyboard controller (83-key)
PNP0301         IBM PC/AT keyboard controller (86-key)
PNP0302         IBM PC/XT keyboard controller (84-key)
PNP0303         IBM Enhanced (101/102-key, PS/2 mouse support)
PNP0304         Olivetti Keyboard (83-key)
PNP0305         Olivetti Keyboard (102-key)
PNP0306         Olivetti Keyboard (86-key)
PNP0307         Microsoft Windows(R) Keyboard
PNP0308         General Input Device Emulation Interface (GIDEI) legacy
PNP0309         Olivetti Keyboard (A101/102 key)
PNP030A         AT&T 302 keyboard
PNP030B         Reserved by Microsoft
PNP0320         Japanese 106-key keyboard A01
PNP0321         Japanese 101-key keyboard
PNP0322         Japanese AX keyboard
PNP0323         Japanese 106-key keyboard 002/003
PNP0324         Japanese 106-key keyboard 001
PNP0325         Japanese Toshiba Desktop keyboard
PNP0326         Japanese Toshiba Laptop keyboard
PNP0327         Japanese Toshiba Notebook keyboard
PNP0340         Korean 84-key keyboard
PNP0341         Korean 86-key keyboard
PNP0342         Korean Enhanced keyboard
PNP0343         Korean Enhanced keyboard 101b
PNP0343         Korean Enhanced keyboard 101c
PNP0344         Korean Enhanced keyboard 103

--Parallel Devices--
PNP0400         Standard LPT printer port
PNP0401         ECP printer port

--Serial Devices--
PNP0500         Standard PC COM port
PNP0501         16550A-compatible COM port
PNP0502         Multiport serial device (non-intelligent 16550)
PNP0510         Generic IRDA-compatible device
PNP0511         Generic IRDA-compatible device

--Disk Controllers--
PNP0600         Generic ESDI/IDE/ATA compatible hard disk controller
PNP0601         Plus Hardcard II
PNP0602         Plus Hardcard IIXL/EZ
PNP0603         Generic IDE supporting Microsoft Device Bay Specification
PNP0700         PC standard floppy disk controller
PNP0701         Standard floppy controller supporting MS Device Bay Spec

--Compatibility with early device ID list--
PNP0802         Microsoft Sound System compatible device (obsolete, use
        PNPB0xx instead)
--Display Adapters--
PNP0900         VGA Compatible
PNP0901         Video Seven VRAM/VRAM II/1024i
PNP0902         8514/A Compatible
PNP0903         Trident VGA
PNP0904         Cirrus Logic Laptop VGA
PNP0905         Cirrus Logic VGA
PNP0906         Tseng ET4000
PNP0907         Western Digital VGA
PNP0908         Western Digital Laptop VGA
PNP0909         S3 Inc. 911/924
PNP090A         ATI Ultra Pro/Plus (Mach 32)
PNP090B         ATI Ultra (Mach 8)
PNP090C         XGA Compatible
PNP090D         ATI VGA Wonder
PNP090E         Weitek P9000 Graphics Adapter
PNP090F         Oak Technology VGA
PNP0910         Compaq QVision
PNP0911         XGA/2
PNP0912         Tseng Labs W32/W32i/W32p
PNP0913         S3 Inc. 801/928/964
PNP0914         Cirrus Logic 5429/5434 (memory mapped)
PNP0915         Compaq Advanced VGA (AVGA)
PNP0916         ATI Ultra Pro Turbo (Mach64)
PNP0917         Reserved by Microsoft
PNP0918         Matrox MGA
PNP0919         Compaq QVision 2000
PNP091A         Tseng W128
PNP0930         Chips & Technologies Super VGA
PNP0931         Chips & Technologies Accelerator
PNP0940         NCR 77c22e Super VGA
PNP0941         NCR 77c32blt
PNP09FF         Plug and Play Monitors (VESA DDC)

--Peripheral Buses--
PNP0A00         ISA Bus
PNP0A01         EISA Bus
PNP0A02         MCA Bus
PNP0A03         PCI Bus
PNP0A04         VESA/VL Bus
PNP0A05         Generic ACPI Bus
PNP0A06         Generic ACPI Extended-IO Bus (EIO bus)


-- Real Time Clock, BIOS, System board devices--
PNP0800         AT-style speaker sound
PNP0B00         AT Real-Time Clock
PNP0C00         Plug and Play BIOS (only created by the root enumerator)
PNP0C01         System Board
PNP0C02         General ID for reserving resources required by Plug and Play
        motherboard registers. (Not specific to a particular device.)
PNP0C03         Plug and Play BIOS Event Notification Interrupt
PNP0C04         Math Coprocessor
PNP0C05         APM BIOS (Version independent)
PNP0C06         Reserved for identification of early Plug and Play
                BIOS implementation.
PNP0C07         Reserved for identification of early Plug and Play
                BIOS implementation.
PNP0C08         ACPI system board hardware
PNP0C09         ACPI Embedded Controller
PNP0C0A         ACPI Control Method Battery
PNP0C0B         ACPI Fan
PNP0C0C         ACPI power button device
PNP0C0D         ACPI lid device
PNP0C0E         ACPI sleep button device
PNP0C0F         PCI interrupt link device
PNP0C10        ACPI system indicator device
PNP0C11         ACPI thermal zone
PNP0C12         Device Bay Controller
PNP0C13         Plug and Play BIOS (used when ACPI mode cannot be used)

--PCMCIA Controller Chipsets--
PNP0E00         Intel 82365-Compatible PCMCIA Controller
PNP0E01         Cirrus Logic CL-PD6720 PCMCIA Controller
PNP0E02         VLSI VL82C146 PCMCIA Controller
PNP0E03         Intel 82365-compatible CardBus controller

--Mice--
PNP0F00         Microsoft Bus Mouse
PNP0F01         Microsoft Serial Mouse
PNP0F02         Microsoft InPort Mouse
PNP0F03         Microsoft PS/2-style Mouse
PNP0F04         Mouse Systems Mouse
PNP0F05         Mouse Systems 3-Button Mouse (COM2)
PNP0F06         Genius Mouse (COM1)
PNP0F07         Genius Mouse (COM2)
PNP0F08         Logitech Serial Mouse
PNP0F09         Microsoft BallPoint Serial Mouse
PNP0F0A         Microsoft Plug and Play Mouse
PNP0F0B         Microsoft Plug and Play BallPoint Mouse
PNP0F0C         Microsoft-compatible Serial Mouse
PNP0F0D         Microsoft-compatible InPort-compatible Mouse
PNP0F0E         Microsoft-compatible PS/2-style Mouse
PNP0F0F         Microsoft-compatible Serial BallPoint-compatible Mouse
PNP0F10         Texas Instruments QuickPort Mouse
PNP0F11         Microsoft-compatible Bus Mouse
PNP0F12         Logitech PS/2-style Mouse
PNP0F13         PS/2 Port for PS/2-style Mice
PNP0F14         Microsoft Kids Mouse
PNP0F15         Logitech bus mouse
PNP0F16         Logitech SWIFT device
PNP0F17         Logitech-compatible serial mouse
PNP0F18         Logitech-compatible bus mouse
PNP0F19         Logitech-compatible PS/2-style Mouse
PNP0F1A         Logitech-compatible SWIFT Device
PNP0F1B         HP Omnibook Mouse
PNP0F1C         Compaq LTE Trackball PS/2-style Mouse
PNP0F1D         Compaq LTE Trackball Serial Mouse
PNP0F1E         Microsoft Kids Trackball Mouse
PNP0F1F         Reserved by Microsoft Input Device Group
PNP0F20         Reserved by Microsoft Input Device Group
PNP0F21         Reserved by Microsoft Input Device Group
PNP0F22         Reserved by Microsoft Input Device Group
PNP0F23         Reserved by Microsoft Input Device Group
PNP0FFF         Reserved by Microsoft Systems

***** Network Adapters - PNP8xxx ***********************
PNP8001         Novell/Anthem NE3200
PNP8004         Compaq NE3200
PNP8006         Intel EtherExpress/32
PNP8008         HP EtherTwist EISA LAN Adapter/32 (HP27248A)
PNP8065         Ungermann-Bass NIUps or NIUps/EOTP
PNP8072         DEC (DE211) EtherWorks MC/TP
PNP8073         DEC (DE212) EtherWorks MC/TP_BNC
PNP8078         DCA 10 Mb MCA
PNP8074         HP MC LAN Adapter/16 TP (PC27246)
PNP80c9         IBM Token Ring
PNP80ca         IBM Token Ring II
PNP80cb         IBM Token Ring II/Short
PNP80cc         IBM Token Ring 4/16Mbs
PNP80d3         Novell/Anthem NE1000
PNP80d4         Novell/Anthem NE2000
PNP80d5         NE1000 Compatible
PNP80d6         NE2000 Compatible
PNP80d7         Novell/Anthem NE1500T
PNP80d8         Novell/Anthem NE2100
PNP80dd         SMC ARCNETPC
PNP80de         SMC ARCNET PC100, PC200
PNP80df         SMC ARCNET PC110, PC210, PC250
PNP80e0         SMC ARCNET PC130/E
PNP80e1         SMC ARCNET PC120, PC220, PC260
PNP80e2         SMC ARCNET PC270/E
PNP80e5         SMC ARCNET PC600W, PC650W
PNP80e7         DEC DEPCA
PNP80e8         DEC (DE100) EtherWorks LC
PNP80e9         DEC (DE200) EtherWorks Turbo
PNP80ea         DEC (DE101) EtherWorks LC/TP
PNP80eb         DEC (DE201) EtherWorks Turbo/TP
PNP80ec         DEC (DE202) EtherWorks Turbo/TP_BNC
PNP80ed         DEC (DE102) EtherWorks LC/TP_BNC
PNP80ee         DEC EE101 (Built-In)
PNP80ef         DECpc 433 WS (Built-In)
PNP80f1         3Com EtherLink Plus
PNP80f3         3Com EtherLink II or IITP (8 or 16-bit)
PNP80f4         3Com TokenLink
PNP80f6         3Com EtherLink 16
PNP80f7         3Com EtherLink III
PNP80f8         3Com Generic Etherlink Plug and Play Device
PNP80fb         Thomas Conrad TC6045
PNP80fc         Thomas Conrad TC6042
PNP80fd         Thomas Conrad TC6142
PNP80fe         Thomas Conrad TC6145
PNP80ff         Thomas Conrad TC6242
PNP8100         Thomas Conrad TC6245
PNP8105         DCA 10 MB
PNP8106         DCA 10 MB Fiber Optic
PNP8107         DCA 10 MB Twisted Pair
PNP8113         Racal NI6510
PNP811C         Ungermann-Bass NIUpc
PNP8120         Ungermann-Bass NIUpc/EOTP
PNP8123         SMC StarCard PLUS (WD/8003S)
PNP8124         SMC StarCard PLUS With On Board Hub (WD/8003SH)
PNP8125         SMC EtherCard PLUS (WD/8003E)
PNP8126         SMC EtherCard PLUS With Boot ROM Socket (WD/8003EBT)
PNP8127         SMC EtherCard PLUS With Boot ROM Socket (WD/8003EB)
PNP8128         SMC EtherCard PLUS TP (WD/8003WT)
PNP812a         SMC EtherCard PLUS 16 With Boot ROM Socket (WD/8013EBT)
PNP812d         Intel EtherExpress 16 or 16TP
PNP812f         Intel TokenExpress 16/4
PNP8130         Intel TokenExpress MCA 16/4
PNP8132         Intel EtherExpress 16 (MCA)
PNP8137         Artisoft AE-1
PNP8138         Artisoft AE-2 or AE-3
PNP8141         Amplicard AC 210/XT
PNP8142         Amplicard AC 210/AT
PNP814b         Everex SpeedLink /PC16 (EV2027)
PNP8155         HP PC LAN Adapter/8 TP (HP27245)
PNP8156         HP PC LAN Adapter/16 TP (HP27247A)
PNP8157         HP PC LAN Adapter/8 TL (HP27250)
PNP8158         HP PC LAN Adapter/16 TP Plus (HP27247B)
PNP8159         HP PC LAN Adapter/16 TL Plus (HP27252)
PNP815f         National Semiconductor Ethernode *16AT
PNP8160         National Semiconductor AT/LANTIC EtherNODE 16-AT3
PNP816a         NCR Token-Ring 4 Mbs ISA
PNP816d         NCR Token-Ring 16/4 Mbs ISA
PNP8191         Olicom 16/4 Token-Ring Adapter
PNP81c3         SMC EtherCard PLUS Elite (WD/8003EP)
PNP81c4         SMC EtherCard PLUS 10T (WD/8003W)
PNP81c5         SMC EtherCard PLUS Elite 16 (WD/8013EP)
PNP81c6         SMC EtherCard PLUS Elite 16T (WD/8013W)
PNP81c7         SMC EtherCard PLUS Elite 16 Combo (WD/8013EW or 8013EWC)
PNP81c8         SMC EtherElite Ultra 16
PNP81e4         Pure Data PDI9025-32 (Token Ring)
PNP81e6         Pure Data PDI508+ (ArcNet)
PNP81e7         Pure Data PDI516+ (ArcNet)
PNP81eb         Proteon Token Ring (P1390)
PNP81ec         Proteon Token Ring (P1392)
PNP81ed         Proteon ISA Token Ring (1340)
PNP81ee         Proteon ISA Token Ring (1342)
PNP81ef         Proteon ISA Token Ring (1346)
PNP81f0         Proteon ISA Token Ring (1347)
PNP81ff         Cabletron E2000 Series DNI
PNP8200         Cabletron E2100 Series DNI
PNP8209         Zenith Data Systems Z-Note
PNP820a         Zenith Data Systems NE2000-Compatible
PNP8213         Xircom Pocket Ethernet II
PNP8214         Xircom Pocket Ethernet I
PNP821d         RadiSys EXM-10
PNP8227         SMC 3000 Series
PNP8228         SMC 91C2 controller
PNP8231         Advanced Micro Devices AM2100/AM1500T
PNP8263         Tulip NCC-16
PNP8277         Exos 105
PNP828A         Intel '595 based Ethernet
PNP828B         TI2000-style Token Ring
PNP828C         AMD PCNet Family cards
PNP828D         AMD PCNet32 (VL version)
PNP8294         IrDA Infrared NDIS driver (Microsoft-supplied)
PNP82bd         IBM PCMCIA-NIC
PNP82C2         Xircom CE10
PNP82C3         Xircom CEM2
PNP8321         DEC Ethernet (All Types)
PNP8323         SMC EtherCard (All Types except 8013/A)
PNP8324         ARCNET Compatible
PNP8326         Thomas Conrad (All Arcnet Types)
PNP8327         IBM Token Ring (All Types)
PNP8385         Remote Network Access Driver
PNP8387         RNA Point-to-point Protocol Driver
PNP8388         Reserved for Microsoft Networking components
PNP8389        Peer IrLAN infrared driver (Microsoft-supplied)
PNP8390         Generic network adapter

***** SCSI, Proprietary CD Adapters - PNPAxxx **********
PNPA002         Future Domain 16-700 compatible controller
PNPA003         Panasonic proprietary CD-ROM adapter (SBPro/SB16)
PNPA01B         Trantor 128 SCSI Controller
PNPA01D         Trantor T160 SCSI Controller
PNPA01E         Trantor T338 Parallel SCSI controller
PNPA01F         Trantor T348 Parallel SCSI controller
PNPA020         Trantor Media Vision SCSI controller
PNPA022         Always IN-2000 SCSI controller
PNPA02B         Sony proprietary CD-ROM controller
PNPA02D         Trantor T13b 8-bit SCSI controller
PNPA02F         Trantor T358 Parallel SCSI controller
PNPA030         Mitsumi LU-005 Single Speed CD-ROM controller + drive
PNPA031         Mitsumi FX-001 Single Speed CD-ROM controller + drive
PNPA032         Mitsumi FX-001 Double Speed CD-ROM controller + drive

***** Sound/Video-capture, multimedia - PNPBxxx ********
PNPB000         Sound Blaster 1.5 sound device
PNPB001         Sound Blaster 2.0 sound device
PNPB002         Sound Blaster Pro sound device
PNPB003         Sound Blaster 16 sound device
PNPB004         Thunderboard-compatible sound device
PNPB005         Adlib-compatible FM synthesizer device
PNPB006         MPU401 compatible
PNPB007         Microsoft Windows Sound System-compatible sound device
PNPB008         Compaq Business Audio
PNPB009         Plug and Play Microsoft Windows Sound System Device
PNPB00A         MediaVision Pro Audio Spectrum
        (Trantor SCSI enabled, Thunder Chip Disabled)
PNPB00B         MediaVision Pro Audio 3D
PNPB00C         MusicQuest MQX-32M
PNPB00D         MediaVision Pro Audio Spectrum Basic
        (No Trantor SCSI, Thunder Chip Enabled)
PNPB00E         MediaVision Pro Audio Spectrum
        (Trantor SCSI enabled, Thunder Chip Enabled)
PNPB00F         MediaVision Jazz-16 chipset (OEM Versions)
PNPB010         Auravision VxP500 chipset - Orchid Videola
PNPB018         MediaVision Pro Audio Spectrum 8-bit
PNPB019         MediaVision Pro Audio Spectrum Basic
        (no Trantor SCSI, Thunder chip Disabled)
PNPB020         Yamaha OPL3-compatible FM synthesizer device
PNPB02F         Joystick/Game port

***** Modems - PNPCxxx-Dxxx****************************
PNPC000         Compaq 14400 Modem (TBD)
PNPC001         Compaq 2400/9600 Modem (TBD)

>
>
>
>But what are these devices?  Can you run 'tree' on this so as to
>visualize the structure better?
>
Sure.  Here's a copy of my tree.

.
|-- bus
|   |-- pci
|   |   |-- devices
|   |   |   |-- 00:00.0 -> ../../../root/pci0/00:00.0
|   |   |   |-- 00:01.0 -> ../../../root/pci0/00:01.0
|   |   |   |-- 00:1e.0 -> ../../../root/pci0/00:1e.0
|   |   |   |-- 00:1f.0 -> ../../../root/pci0/00:1f.0
|   |   |   |-- 00:1f.1 -> ../../../root/pci0/00:1f.1
|   |   |   |-- 00:1f.2 -> ../../../root/pci0/00:1f.2
|   |   |   |-- 00:1f.3 -> ../../../root/pci0/00:1f.3
|   |   |   |-- 01:09.0 -> ../../../root/pci0/00:1e.0/01:09.0
|   |   |   |-- 01:09.1 -> ../../../root/pci0/00:1e.0/01:09.1
|   |   |   |-- 01:0a.0 -> ../../../root/pci0/00:1e.0/01:0a.0
|   |   |   `-- 01:0b.0 -> ../../../root/pci0/00:1e.0/01:0b.0
|   |   `-- drivers
|   |       |-- Ensoniq AudioPCI
|   |       |-- agpgart
|   |       |-- cardbus
|   |       |-- e100
|   |       |-- parport_pc
|   |       `-- uhci-hcd
|   |-- pnp
|   |   |-- devices
|   |   |   |-- 00 -> ../../../root/pnp/00
|   |   |   |-- 01 -> ../../../root/pnp/01
|   |   |   |-- 02 -> ../../../root/pnp/02
|   |   |   |-- 03 -> ../../../root/pnp/03
|   |   |   |-- 04 -> ../../../root/pnp/04
|   |   |   |-- 05 -> ../../../root/pnp/05
|   |   |   |-- 06 -> ../../../root/pnp/06
|   |   |   |-- 07 -> ../../../root/pnp/07
|   |   |   |-- 08 -> ../../../root/pnp/08
|   |   |   |-- 09 -> ../../../root/pnp/09
|   |   |   |-- 0b -> ../../../root/pnp/0b
|   |   |   |-- 0c -> ../../../root/pnp/0c
|   |   |   |-- 0d -> ../../../root/pnp/0d
|   |   |   |-- 0e -> ../../../root/pnp/0e
|   |   |   |-- 0f -> ../../../root/pnp/0f
|   |   |   |-- 10 -> ../../../root/pnp/10
|   |   |   |-- 11 -> ../../../root/pnp/11
|   |   |   |-- 12 -> ../../../root/pnp/12
|   |   |   `-- 13 -> ../../../root/pnp/13
|   |   `-- drivers
|   |-- scsi
|   |   |-- devices
|   |   `-- drivers
|   |       |-- sd
|   |       |-- sg
|   |       `-- sr
|   `-- usb
|       |-- devices
|       |   |-- 00:1f.2-0:0 -> 
../../../root/pci0/00:1f.2/usb_bus/00:1f.2-0:0
|       |   `-- 00:1f.2-1:0 -> 
../../../root/pci0/00:1f.2/usb_bus/1/00:1f.2-1:0
|       `-- drivers
|-- class
|   `-- input
|       |-- devices
|       |-- drivers
|       `-- mouse
`-- root
    |-- pci0
    |   |-- 00:00.0
    |   |   |-- irq
    |   |   |-- name
    |   |   |-- power
    |   |   `-- resource
    |   |-- 00:01.0
    |   |   |-- irq
    |   |   |-- name
    |   |   |-- power
    |   |   `-- resource
    |   |-- 00:1e.0
    |   |   |-- 01:09.0
    |   |   |   |-- irq
    |   |   |   |-- name
    |   |   |   |-- power
    |   |   |   `-- resource
    |   |   |-- 01:09.1
    |   |   |   |-- irq
    |   |   |   |-- name
    |   |   |   |-- power
    |   |   |   `-- resource
    |   |   |-- 01:0a.0
    |   |   |   |-- irq
    |   |   |   |-- name
    |   |   |   |-- power
    |   |   |   `-- resource
    |   |   |-- 01:0b.0
    |   |   |   |-- irq
    |   |   |   |-- name
    |   |   |   |-- power
    |   |   |   `-- resource
    |   |   |-- irq
    |   |   |-- name
    |   |   |-- power
    |   |   `-- resource
    |   |-- 00:1f.0
    |   |   |-- irq
    |   |   |-- name
    |   |   |-- power
    |   |   `-- resource
    |   |-- 00:1f.1
    |   |   |-- irq
    |   |   |-- name
    |   |   |-- power
    |   |   `-- resource
    |   |-- 00:1f.2
    |   |   |-- irq
    |   |   |-- name
    |   |   |-- power
    |   |   |-- resource
    |   |   `-- usb_bus
    |   |       |-- 00:1f.2-0:0
    |   |       |   |-- altsetting
    |   |       |   |-- name
    |   |       |   `-- power
    |   |       |-- 1
    |   |       |   |-- 00:1f.2-1:0
    |   |       |   |   |-- altsetting
    |   |       |   |   |-- name
    |   |       |   |   `-- power
    |   |       |   |-- configuration
    |   |       |   |-- manufacturer
    |   |       |   |-- name
    |   |       |   |-- power
    |   |       |   `-- product
    |   |       |-- configuration
    |   |       |-- manufacturer
    |   |       |-- name
    |   |       |-- power
    |   |       |-- product
    |   |       `-- serial
    |   |-- 00:1f.3
    |   |   |-- irq
    |   |   |-- name
    |   |   |-- power
    |   |   `-- resource
    |   |-- name
    |   `-- power
    |-- pnp
    |   |-- 00
    |   |   |-- name
    |   |   `-- power
    |   |-- 01
    |   |   |-- name
    |   |   `-- power
    |   |-- 02
    |   |   |-- name
    |   |   `-- power
    |   |-- 03
    |   |   |-- name
    |   |   `-- power
    |   |-- 04
    |   |   |-- name
    |   |   `-- power
    |   |-- 05
    |   |   |-- name
    |   |   `-- power
    |   |-- 06
    |   |   |-- name
    |   |   `-- power
    |   |-- 07
    |   |   |-- name
    |   |   `-- power
    |   |-- 08
    |   |   |-- name
    |   |   `-- power
    |   |-- 09
    |   |   |-- name
    |   |   `-- power
    |   |-- 0b
    |   |   |-- name
    |   |   `-- power
    |   |-- 0c
    |   |   |-- name
    |   |   `-- power
    |   |-- 0d
    |   |   |-- name
    |   |   `-- power
    |   |-- 0e
    |   |   |-- name
    |   |   `-- power
    |   |-- 0f
    |   |   |-- name
    |   |   `-- power
    |   |-- 10
    |   |   |-- name
    |   |   `-- power
    |   |-- 11
    |   |   |-- name
    |   |   `-- power
    |   |-- 12
    |   |   |-- name
    |   |   `-- power
    |   |-- 13
    |   |   |-- name
    |   |   `-- power
    |   |-- name
    |   `-- power
    |-- scsi0
    |   |-- name
    |   `-- power
    `-- sys
        |-- 0020
        |   |-- name
        |   `-- power
        |-- 0040
        |   |-- name
        |   `-- power
        |-- 03?0
        |   |-- name
        |   `-- power
        |-- name
        `-- power

101 directories, 113 files


>
>
>>>Also a few minor comments on the patch:
>>>  - pnpbios_bus_type should probably be made static, along with
>>>    alloc_pnpbios_root().
>>>
>>alloc_pnpbios_root is now static.  I'm going to leave bus_type as it is 
>>because I want it open to other files at least for now.
>>
>
>Why?  I don't think there's a need for any other code to need to point
>to it.  If in the future it's needed, you can always export it :)
>
Ok, I'll make it static too.

>
>
>>>  - in pnpbios_bus_match(), don't you have to check the value of
>>>    the call to match_device() to make sure you have a match?
>>>    That would keep pnpbios_device_probe() from being called for
>>>    every device like it looks your patch causes.
>>>
>>I did some serious restructuring here and in pnpbios_device_probe.  Also 
>>I made it a bit more like the one used by pci.  Hopefully it's all right 
>>now.
>>
>
>Wrong placement of your {} in the while statement :)
>You also might want to not hard code the "7" in the memcmp, but use the
>size of the smaller field there, incase things change in the future.
>
I fixed the {}. :-)   The pnpbios driver only supports dev ids with the 
length of 7.  Any shorter or longer would be considered invalid by the 
PNPBIOS Specifications.  Therefore it makes sence to force it to use a 
length of 7.  Look at the devid list I included.

>
>
>>>  - the pnpbios_device_probe() call should return a negative error
>>>    number if the device does not match, or some error happens.
>>>    Returning 1 does not mean success.  You also need to save off
>>>    the device specific info somehow in your structure, so that
>>>    the pnpbios_device_remove() can remove it.  Or am I just
>>>    missing something here?
>>>
>>pnpbios_device_probe now returns a negative number on failure.  I'm 
>>creating a more flexible pnpbios specific device data structure that can 
>>be used instead of pci_dev in my next patch.  I should be able to clean 
>>some of this up once I do that.  I'll take care of the device specific 
>>info then.
>>
>
>But it still looks like you aren't saving off the needed information in
>the dev.driver_data structure.  Or am I missing something?
>
Ok, I'll store the info to dev.driver_data for now.

>
>
>thanks,
>
>greg k-h
>
Thanks,
Adam

[PATCH] 2.5.32 port PnP BIOS to the driver model - ready for inclusion

[Adam Belay]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

Now that all issues have been resolved and it has been tested, I feel 
that this patch is ready to be included in the official tree.  Thanks to 
Greg for pointing these issues out.  If one of you could please forward 
this to Linus, I'd greatly appreciate it.  Also could you please resend 
this with the patch inline because if I do netscape mail will remove all 
the tabs. :-)
Thanks,
Adam

[-- Attachment #2: pnpbios1-final.patch.gz --]
[-- Type: application/octet-stream, Size: 2788 bytes --]