From: Greg KH <greg@kroah.com>
To: Adam Belay <ambx1@netscape.net>
Cc: Patrick Mochel <mochel@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.5.32 port PnP BIOS to the driver model RESEND #1
Date: Thu, 29 Aug 2002 22:28:23 -0700 [thread overview]
Message-ID: <20020830052823.GE6486@kroah.com> (raw)
In-Reply-To: <3D6E85B1.4040708@netscape.net>
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
next prev parent reply other threads:[~2002-08-30 5:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-16 22:36 [PATCH] 2.5.31 driverfs: patch for your consideration Adam Belay
2002-08-17 3:06 ` Greg KH
2002-08-17 14:10 ` Adam Belay
2002-08-17 19:03 ` Greg KH
2002-08-17 22:32 ` Adam Belay
2002-08-18 21:46 ` Greg KH
2002-08-18 21:47 ` Greg KH
2002-08-23 17:45 ` [PATCH] 2.5.31 port PnP BIOS to the driver model Adam Belay
2002-08-27 21:40 ` [PATCH] 2.5.32 port PnP BIOS to the driver model RESEND #1 Adam Belay
2002-08-28 5:14 ` Greg KH
2002-08-29 20:36 ` Adam Belay
2002-08-30 5:28 ` Greg KH [this message]
2002-08-30 14:47 ` Adam Belay
2002-08-30 14:48 ` [PATCH] 2.5.32 port PnP BIOS to the driver model - ready for inclusion Adam Belay
2002-08-19 18:10 ` [PATCH] 2.5.31 driverfs: patch for your consideration Patrick Mochel
2002-08-19 15:35 ` Adam Belay
2002-08-17 13:52 ` David D. Hagood
2002-08-17 19:43 ` Alan Cox
2002-08-19 18:19 ` Patrick Mochel
2002-08-19 15:50 ` Adam Belay
2002-08-19 19:59 ` Greg KH
2002-08-19 21:54 ` Adam Belay
2002-08-20 3:32 ` Greg KH
2002-08-20 6:51 ` jw schultz
2002-08-20 18:32 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020830052823.GE6486@kroah.com \
--to=greg@kroah.com \
--cc=ambx1@netscape.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox