[lkml]   [2002]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] 2.5.32 port PnP BIOS to the driver model RESEND #1
On Thu, Aug 29, 2002 at 08:36:01PM +0000, Adam Belay wrote:
> 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

> 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?


greg k-h
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.120 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site